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ОСНОВНЫЕ ПОНЯТИЯ 


Основные понятия 


омплекс тестирования ЕСУ (ЕМУ Саха Уейбсаноп) предназначен для 

тестирования ЕМУ-приложений на смарт-картах. ВСУ позволяет 

проверить полноту данных на карте и работоспособность карты при 

обслуживании транзакций, непротиворечивость и отсутствие 
избыточности данных, контролировать выполнение криптографических 
функций ЕМУ-приложения, выявить причины сбоев в работе уже 
выпущенных карт, и ещё многое другое. 


ЕСУ — это эмулятор терминала в торговой точке (РОЗ-терминала) с целым 
рядом дополнительных возможностей, которых нет в РОЗ-терминале. ЕМУ- 
приложение, тестируемое ЕСУ, может быть размещено как на контактной 
карте (удовлетворяющей спецификациям ТЗО/ТЕС 7816), так и на 
бесконтактной карте или мобильном устройстве (взаимодействие с которыми 
осуществляется на основе протоколов, описанных в 150 14443). Платежное 
приложение выбирает режим обработки транзакции (контактный или 
бесконтактный) автоматически в зависимости от метода использования 
носителя. Поэтому платежный аплет может быть размещен и на карте с двумя 
видами интерфейсов — контактным и бесконтактным (4аа| пиеёасе сад). 
Мобильное устройство всегда осуществляег коммуникацию с РОЗ- 
терминалом через МЕС и эмулирует работу бесконтактной карты. 


Хотя ЕСУ эмулирует обработку транзакции в контактном и бесконтактном 
режимах, но между этими режимами существует болышая разница. В 
контактном режиме любое ЕМУ-приложение работает в соответствии со 
спецификациями, определенными в ЕМУ. Ниеотие4 Сисай Сага Зресйса- 
Чопз Юг Раутепе Зузепаз. ВооК 1-4, а в бесконтактном — по спецификациям 
ЕМУ Сопас@езз бреайсаноп$ Юг Рауплепе 5узвепл5. Это связано с тем, что в 
бесконтактном режиме из-за определенных ограничений нельзя полностью 
поддержать тот же алгоритм обработки транзакции, что в контактном режиме. 


Для бесконтактного режима нет единой спецификации. Каждая платежная 
система (например, \У15а, МазегСаха, ...) реализовала собственный алгоритм 
обработки в бесконтактном режиме, и спецификации ЕМУ Сопас4езз 
Зрессавопз ог Рауплепе Зузетл$ — это не более, чем набор общих положений 
об обработке бесконтактной транзакции в РОЗ-терминале. Для каждой 


платежной системы вводится понятие ядра (Кегпе), которое отвечает за 
обработку бесконтактной транзакции для этой (и только этой) системы. 
Сведений, приведенных в спепификациях ЕМУ СогасЧезз бресмйсаНопз, 
обычно недостаточно для реализации ядра обработки бесконтактной транз- 
акции в терминале. Кроме открытых спецификаций ЕМУ Сопас4ез$ 
Зрессавопз нужны ещё спецификации работы платежного приложения в 
бесконтактном режиме для конкретной платежной системы. А эти 
спецификации предоставляются только партнерам платежной системы 
(проще говоря, покупаются за немалые деньи). 


В связи с этим основная разница обработки контактной и бесконтактной 
транзакции в ЕСУ состоит в следующем. 


® Обработка контактной транзакции регламентируется строгими специфи- 
кациями ЕМУ. Циеогоеа Сисай Сага ЗресмНсаноп$ Юг Раутепе Зузетлз, в 
связи с чем этот процесс полностью определен и может быть выполнен 
эмулятором терминала для ЕМУ-приложения любой платежной системы. 


® Обработка бесконтактной транзакции описывается общими специфика- 
циями ЕМУ Сошас@езз брессаЧопз$ и зависит от платежной системы. 
Эмулятор терминала выполняет обработку бесконтактной транзакции не 
для всех, а только для некоторых платежных систем. 


Перед тем как начать использовать комплекс тестирования ЕСУ, рекоменду- 
ется ознакомиться со следующими понятиями: 

®  формаг объектов данных, которыми обмениваются карта и терминал 

® — основные этапы выполнения транзакции в контактном режиме 

® — особенности выполнения транзакции в бесконтактном режиме. 


Крагкое объяснение этих сущностей приведено в последующих разделах 
главы. Если вы хорошо знакомы с рассматриваемым вопросом, можете 
перейти к следующей главе. 


ОСНОВНЫЕ ПОНЯТИЯ 


Любое ЕМУ-приложение использует некоторый набор элементов данных. 
Элементы данных являются логическими структурами, которые при 
необходимости (например, при передаче данных в терминал) отображаются в 
объекты данных. Существуют различные способы отображения элементов 
данных в объекты данных. В спецификациях ЕМУ используется кодирование 
ВЕВ-ТТУ, формализованное в стандарте 1ЗО/ТЕС 8825. В соответствии с 
15О/ТЕС 8825 любой объекг данных определяется двумя или тремя полями: 
тэгом (Гао), длиной (Глепо) и значением (Уаюе). Поле значения должно быть 
опушено, если длина равна 0. Поле тэга состоит из одного или более байтов 
(в спецификациях ЕМУ -— один или два байта). Структура поля тэга показана 
в следующих таблицах. 


Структура первого байта поля тэга. 


8 7 6 5 4 З3 2 Т Значение 
хх Класс объекта данных 
0 Примитивный объект 
Составной объект 
1 1 1 1 1 — Имеются другие байты тэга 
х х Хх Хх Хх Номертэга 


Структура последующих байтов поля тэга. 


8 7 6 5 4 3 2 1 Значение 
Имеются другие байты тэга 
0 Последний байт поля тэга 
х х х Хх Хх Хх Хх Номертоэга (больше 0) 


Два первых бита первого байта поля тэга определяют класс объекта данных 
следующим образом: 


=" 00 универсальный класс 


" 01 — прикладной класс, который содержит объекты, относящиеся к 
определенной индустрии (например, индустрии расчетов по карточкам) 


10 — контекстно-определенный класс (содержит объекты, определенные 
для некоторого стандарта) 


11 — частный класс, содержащий объекты, которые определены 
конкретными спецификациями 


Для труппирования данных используются составные объекты данных, 
которые могут содержать другие составные объекты и примитивные объекты. 


В сиецификациях ЕМУ составной объекг данных называется ‘етарае 
(например, ЕСГ Тетра). 


Поле длины объекта данных определяет количество байт в поле значения 
объекта. В стандарте ЕМУ поле длины задается одним, двумя или тремя 
байтами. Если старший бит самого левого байта поля длины равен 0, то поле 
длины занимает один байт и определяет длину значения от 0 до 127. Нсли 
старший бит равен 1, то последующие биты определяют количество 
дополнительных байтов, используемых для представления поля длины. 


Описанный выше метод кодирования данных ВЕК-ГШЛМ позволяет для 
конкретного объекта данных однозначно определить его идентификатор, 
размер и значение. ’Таким образом, кодировка ВЕВ-ГЛ является 
универсальным средством представления данных. 


Для выполнения ряда команд карте требуются параметры транзакции и 
возможности терминала. Для большинства ЕМУ-приложений такие данные 
требуются для первой и второй команд СЕМЕКАТЕ АС, а также для команды 
СЕТ РКОСЕ$$М С ОРТОМ$. Список объектов данных, необходимых для 
выполнения команды, в общем случае называется Оаёа ОБесе [454 (РОГ). Для 
конкретных команд названия списков уточняются. Например: 


" Саа В5кК Мапаоетейе Оаа ОБесе Г45ё 1 (СООГЛ) — список объектов 
данных для первой команды СЕМЕКАТЕ АС 


" Саа В5кК Мапаоетейе Оаа ОБесе Г45 2 (СООТ) — список объектов 
данных для второй команды СЕМЕКАТЕ АС 


"=  Росеззше Орнопз аа ОБесе [45 (РООТ) — список объектов данных для 
команды СЕТ РКОСЕ$$ МС ОРПОМ5 


Любой список объектов данных представляет собой перечень тэгов и длин 
объектов данных, которые должны быть переданы карте. Все списки 
записываются на карту в процессе её персонализации и считываются 
терминалом по команде КЕАО ВЕСОВ. Терминал в соответствующих 
командах передает только значения объектов, перечисленных в списках. 


На рис. 1 показана общая схема обработки транзакции в контактном режиме. 
Приведенная диаграмма не отображает все особенности карточной операции 
в терминале, но позволяет понять, каким образом в этой операции участвует 
карта (платежное приложение). Кроме того, в нижеслелующем описании 
обработки транзакции в контактном режиме отсутствуют важные детали, 
которые опущены, поскольку целью документа является не определение 
процесса обработки транзакции, а описание процесса взаимодействия 
терминала и карты. 


Платежная операция начинается с выбора терминалом платежного 
приложения на карте. Для выполнения транзакции необходимо, чтобы 
терминал поддерживал платежное приложение, которое находится на карте. 
На этапе выбора приложения терминал проверяет факг наличия такого 
приложения (если на карте несколько приложений, поддерживаемых 
терминалом, то терминал и, возможно, владелец карты выбирают, какое из 
них следует использовать для выполнения текущей транзакции). 


Существует два способа выбора приложения: выбор через РЗЕ, (Рауплепе 
Зумет Нпунопитеп и прямой выбор. РЗЕ — это список с идентификатором 
1РАУ.5У$.ОШНО1, в котором перечислены все платежные приложения на 
карте. Но РЗЕ не является обязательным. Поэтому терминал может отыскать 
на карте все приложения, которые он обрабатывает, и составить свой список 
кандидатов для обработки. В любом случае для выбора обрабатываемого 
приложения используется команда ЗЕГЕСТ, в результате выполнения 
которой терминалу передаются некоторые данные о выбранном платежном 
приложении.1 


После того как приложение выбрано, терминал инициирует транзакцию. Для 
этого используется команда СЕТ РКОСЕЗ$$ ИМС ОРТЮМ5$, с помощью 
которой терминал сообщает карте данные, необходимые ей для того, чтобы 
определиться с особенностями выполняемой операции.? В ответе на команду 
СЕТ РКОСЕ$$ МС ОРПОМ$ карта сообщает терминалу о своих 
возможностях по выполнения транзакции и требованиях к терминалу (через 
АррИсаноп ИиегсБапое РгоШе — АП?) и предоставляет ссылки на данные, 
которые терминал должен прочитать, чтобы успешно выполнить транзакцию 
(определяются в АррИсачоп Ее Госаог — АРГ). 


1 Эти данные называются ЕЙе Сопмо! ш{ютаНоп (ЕСТ) и содержат идентификатор приложения 
(АП), метку приложения и предпочтительные языки общения терминала с владельцем карты. 


2 Данные, необходимые карте для инициирования транзакции, определяются в списке Ргосеззше 
ОрНоп$ Ра ОЪесе Г45ё (РООГ), предоставляемом в ответ на команду ЗЕГЕСТ. Если никакие 
данные от терминала не нужны, то список РООГ отсутствует, и с командой СЕТ 
РКОСЕ$$1\МС ОРТЮМ$ никакие данные не передаются. 


ОСНОВНЫЕ ПОНЯТИЯ 


Терминал 


Онлайновая обработка транзакции 
и критичный скрипт-процессинг 


Команды скрипта 


_  КЕАО ВЕСОВ — — 


СЕМЕВАТЕ АСТ — 


Предоставление карте решения 
эмитента об обработке транзакции 


_  СЕМЕВАТЕ АС2 


Некритичный скрипт-процессинг 


Команды скрипта | 


Платежная карта 


® Возвращает в ответ на команду 
ЗЕЁЕСТ информацию о платежном 


приложении (ЕС!) 


Инициализирует транзакцию и 
возвращает в ответ на команду СЕТ 
РВОСЕЗУМ6 ОРТЮОМ$ возможности 
карты по обработке транзакции (А!Р) 
и перечень данных, которые должны 
быть прочитаны терминалом (АЕ|) 


Предоставляет данные приложения 
из указанной записи 


Проверяет Р!№-код, предоставленный 
терминалом в открытом или зашиф- 
рованном виде и сообщает термина- 
лу о результате проверки 


Анализирует решение терминала об 
обработке транзакции, выполняет 
процедуры управления рисками, 
оценивает результаты и сообщает 
терминалу о своем решении об 
обработке транзакции 


Выполняет обработку критичных 
команд, переданных эмитентом для 
модификации параметров 
платежного приложения 


Проверяет данные, присланные эми- 
тентом, и принимает окончательное 
решение об обработке транзакции, о 
котором сообщает терминалу 


Выполняет обработку некритичных 
команд, переданных эмитентом для 
модификации параметров 
платежного приложения 


Рис. 1. Обработка транзакции в контактном режиме. 


'Терминал считывает все записи, указанные картой, с помощью команд ВЕАР 
ВЕСОЕКДО и приступает к выполнению офлайновой аутентификации данных, 
предоставленных картой. В этот момент полностью может быть выполнена 
только аутентификация по методу ЗРА или ОПА. Аутентификация данных 
по методу СА (в сиду особенностей реализации) выполняется полностью 
только после получения ответа от первой команды СЕМЕКАТЕ АС. 


Затем терминал приступает к выполнению процедур проверки ограничений 
по применению приложения (сверяются номера версий, проверяется срок 
действия карты ит. п.) и контролю СТОП-ЛИСТОВ. 


Терминал просматривает список методов верификации владельца карты, 
предоставленный картой, выбирает подходящий метод и верифицирует 
владельца карты. 


'Терминал по указанию карты может также выполнить процедуры управления 
рисками, контролирующие сумму и количество последовательных 
транзакций, выполненных в Оше. 


Далее терминал производит анализ результатов выполненных им проверок с 
использованием критериев, сформулированных терминалу обслуживающим 
банком и эмитентом карты. В результате терминал принимает одно из трех 
решений об обработке транзакции: 


1. Одобрить транзакцию в офлайновом режиме. 
2. Передать транзакцию на авторизацию эмитенту карты. 
3. Отвергнуть транзакцию в офлайновом режиме. 


О своём решении терминал сообщает карте с помощью первой команды 
СЕМЕКАТЕ АС. Вместе с командой СЕМЕКАТЕ АС карте передаются 
данные транзакции, результаты процедуры управления рисками терминала и 
реквизиты ‘терминала. На основе полученных данных карта выполняет 
собственные процедуры управления рисками и производит анализ 
результатов выполненных ею проверок с использованием критериев, 
сформулированных эмитентом карты. В результате карта принимает 
собственное решение об обработке транзакции — одно из трех решений, 
описанных выше, но ранг решения карты всегла не ниже ранга решения 
терминала (например, если терминал принял решение отвергнуть 
транзакцию, то карта не имеет права изменить это решение). В ЕМУ эта 
зависимость является фундаментальной и контролируется как картой, так и 
терминалом. 


Если карта принимает решение о том, что транзакция должна быть 
отправлена на авторизацию эмитенту, то карта формирует специальную 
криптограмму, представляющую собой ПОДПИСЬ реквизитов транзакции, 
карты и терминала. Во всех остальных случаях формируются криптограммы, 


информирующие о завершении транзакции (одобрении или отклонении 
транзакции в офлайновом режиме). Кроме того, в случае использования 
метода аутентификации СОА криптограмма заносится в специальный пакет 
данных, который заптифровывается на ключе карты и служит для офлайновой 
аутентификации данных терминалом. 


'Терминал, получив данные от карты по команде СЕМЕКАТЕ АС, выполняет 
аутентификацию карты, если применяется метод аутентификации СОА 
(расшифровывает пакет данных с криптограммой и убеждается, что данные в 
пакете корректны). Затем терминал проверяет, какую криптограмму вернула 
карта. Если возвращена криптограмма одобрения или отклонения транзакции 
в офлайновом режиме, то обработка на этом завершается. Когда транзакция 
должна быть отправлена на авторизацию эмитенту, терминал отправляет 
(через хост обслуживающего банка) криптограмму и другие относящиеся к 
транзакции данные эмитенту. 


Получив данные, эмитент авторизует транзакцию (проверяет криптограмму и 
некоторые другие параметры). По результатам этих проверок эмитент 
принимает решение о том, отклонить или одобрить транзакцию, и, в свою 
очерель, формирует криптограмму, которая используется картой для 
аутентификации эмитента. Ответ эмитента отправляется обслуживающему 
банку, который направляет его терминалу. 


В омлвете эмитента могут присутствовать команды скрипт-процессинга, 
предназначенные для карты. С помощью этих команд эмитент имеет 
возможность менять параметры платежного приложения, разблокировать или 
изменить РИ\-код, заблокировать приложение карты. Эмитент может 
присвоить каждой команде скрипт-процессинга статус критичной (команда 
направляется карте сразу после получения её терминалом до выполнения 
проверки ответа эмитента) или некритичной (команда передается карте после 
выполнения проверки ответа эмитента). 


Терминал, получив ответ эмитента, передает карте решение эмитента, 
криптограмму эмитента и уточненные данные своих проверок во второй 
команде СЕМЕКАТЕ АС (или команде ЕХГЕКМАГ, АОТНЕХПСАТЕ, если 
платежное приложение использует эту команду для проверки ответа 
эмитента). Карта аутентифицирует эмитента путем проверки криптограммы. 
Если аутентификация эмитента прошла успешно, то карта выполняет 
решение эмитента о завершении транзакции и формирует криптограмму 
одобрения или отклонения транзакции. Когда аутентификация эмитента 
провалилась, транзакция обычно отвергается. 


Ниже приводится более подробное описание отдельных этапов обработки 
транзакции и объектов данных, которыми обмениваются терминал и карта. 


Данные, которые необходимы для выполнения транзакции, считываются 
терминалом из записей файлов платежного приложения по команде КЕАР 
ВЕСОВО. Но не все данные, которые могут потребоваться терминалу, 
расположены в записях файлов. Некоторые данные хранятся в виде отдельных 
объектов и при необходимости терминал извлекает их с карты с помошью 


команды СВТ ОАТА. 


Важнейшим свойством платежного приложения является использование 
криптографических функций для повышения безопасности финансовых 
операций. Основные задачи для повышения безопасности финансовых 
операций, решаемые приложением, следующие. 


1. Обеспечение аутентификации приложения на карте (или аутентифика- 
ции карты). Под аутентификацией карты понимается процесс доказа- 
тельства её подлинности, т. е. того факта, что карта эмитирована банком, 
авторизованным на эмиссию карт. В случае офлайновой транзакции 
эмитент полностью делегирует карте функцию принятия решения по 
результату выполнения операции. Очевидно, что можно доверять только 
решениям карты, подлинность которой доказана. Поэтому так важна её 
надежная аутентификация. Аутентификация карты осуществляется терми- 
налом и (или) эмитентом. В офлайновых операциях аутентификация 
карты производится только терминалом и называется офлайновой 
аутентификацией. В случае онлайновой транзакции аутентификация 
карты может осуществляться и терминалом, и эмитентом. Аутентифика- 
ция карты, выполняемая эмитентом, называется онлайновой. 


2. Обеспечение аутентификации эмитента и проверки целостности 
присылаемых им данных за счёт проверки подписей данных, 
формируемых эмитентом. 


3. Гарантирование эмитенту невозможности отказа держателя его карты от 
результата выполненной операции. Это обеспечивается тем, что по 
каждой выполненной транзакции эмитент получает от карты в своё 
распоряжение криптограмму приложения, которая представляет собой 
подпись наиболее критичных данных транзакции. Соответствие 
криптограммы данным транзакции подтверждает факт её выполнения. 


4. Проверка целостности обмена критическими данными между картой и 
терминалом. 


5. Обеспечение конфиденциальности данных в информационном обмене 
между картой и эмитентом, картой и терминалом. 


ОСНОВНЫЕ ПОНЯТИЯ 


6. Предоставление механизма надежной верификации владельца карты с 
помошью офлайновой проверки РП\-кода. 


Платежное приложение реализует функции обеспечения безопасности 
транзакции на используемых в стандарте ЕМУ асимметричном алгоритме 
шифрования ВЗА и симметричном алгоритме шифрования ОЕ5. 


Сначала рассмотрим алгоритм шифрования К$ЗА. Если отвлечься от 
терминологии В$А, которая иногда может только запутать, то асимметричное 
шифрование основывается на том, что существуют два ключа — публичный и 
секретный. Если данные затифрованы на публичном ключе, то они могут 
быть расшифрованы на секретном ключе и наоборот. Необходимость 
применения асимметричных алгоритмов шифрования в процедурах 
обеспечения безопасности вызвана тем, что терминал не должен обладать 
секретами карты (симметричное шифрование всегда подразумевает знание 
участниками информационного обмена общего секрета). 


Для того чтобы терминал мог использовать асимметричные ключи карты для 
реализации функций обеспечения безопасности, необходимо создание РК]- 
инфраструктуры (РКТ — Рас Кеу ШНазвасвиие). РК]-инфраструктура 


платежной системы в соответствии со стандартом ЕМУ показана на рис. 2. 


Эмитент Сегийса оп АщПогйу 


1СС РИмайе Кеу ЮС РИ Кеу 155 цег Рима{е Кеу 1 155цег РЫЫ К Кеу СА Рима{е Кеу СА РИЫБс Кеу 
сс Рес Я РИ! $са Рса 


Обслуживающий банк 


Хранилище ключей 


Платежное приложение Терминал 


Рис. 2.РКГ-инфраструктура платежной системы. 


Корнем РКГинфраструктуры является центр сертификации (Сегайсаноп 
Аифойбу — СА) платежной системы. Центр сертификации генерирует пары 
ключей В$А (открытых и секретных) и рассылает открытые ключи обслужива- 
ющим банкам для их загрузки в терминалы платежной системы. На втором 
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уровне дерева РК]-инфраструктуры находятся центры сертификации эмитен- 
тов-участников платежной системы. Эти центры также генерируют пары 
ключей В$А и получают в СА сертификаты открытых ключей. Сертификат 
открытого ключа представляет собой реквизиты открытого ключа (включая и 
сам открытый ключ), его срок действия, идентификатор эмитента и т. п., 
подписанные на секретном ключе центра сертификации платежной системы. 


Наконец, на нижнем уровне инфраструктуры располагаются открытые и 
секретные ключи карт эмитента. Открытые ключи карт подписываются в 
центре сертификации эмитента на секретном ключе центра сертификации 
эмитента. 


В процессе персонализации платежного приложения на карту записываются 
сертификаты открытого ключа эмитента и открытого ключа карты, а также 
секретный ключ карты. 


Для того чтобы получить открытый ключ карты, терминал считывает с карты 
сертификаты открытых ключей эмитента и карты. Далее с помощью 
открытого ключа СА, хранящегося в терминале, терминал проверяет 
правильность сертификата открытого ключа эмитента.2 


После доказательства правильности сертификата открытого ключа эмитента 
терминал с помощью восстановленного открытого ключа эмитента проверяет 
правильность сертификата открытого ключа карты. Если сертификат 
корректен, то терминал получает доступ к открытому ключу карты. Открытый 
ключ карты используется терминалом для аутентификации приложения на 
карте и заифрования конфиденциальных данных, пересылаемых приложе- 
нию (например, РИ\-кода). Аутентификация приложения осуществляется 
путем проверки подписи определенных данных, сформированной картой на 
секретном ключе карты. Если подпись карты верна, то это означает, что она 
была сделана секретным ключом карты, соответствующим её открытому 
ключу, сертифицированному эмитентом. Это в свою очерель означает, что 
карта была эмитирована банком-эмитентом, открытый ключ которого был 
сертифицирован центром сертификации платежной системы. ‘Таким 
образом, доказывается Факт выпуска карты банком, уполномоченным 
эмитировать карты платежной системы. 


Для формирования криптограмм приложения, подписей данных, 
передаваемых между эмитентом и картой, а также для зашифрования обмена 


ТВ терминологии ЕМУ для формирования сертификатов используется функция $1оп на секретном 
ключе. Эта функция зашифровывает сертификат на секретном ключе и он может быть 
расшифрован только на открытом ключе, соответствующем секретному ключу. 


2 Сертификат расшифровывается на публичном ключе. В терминологии ЕМУ эта функция 
называется Весоуег. В результате расшифрования сертификата терминал получает доступ к 
открытому ключу эмитента, который хранится в сертификате. Но в сертификате может храниться 
не весь открытый ключ эмитента, а только его часть. Другая часть ключа извлекается из объекта 
данных, который называется 155аег РиБ с Кеу Кеташает. 
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конфиденциальными данными между ними, используется симметричный 
алгоритм ЗОН$ ($0 11568-2). В этом случае участники информационного 
обмена имеют общий секрет — секретный ключ ЗОЕ$. Вернее, набор 
секретных ключей, поскольку в целях безопасности платежное приложение и 
эмитент используют несколько ключей. 


Справедливости ради нужно сказать, что набор секретных ключей в 
платежном приложении определяется разработчиком. Поэтому говорить о 
каких-то стандартах не приходится. Для примера можно привести, какие 
ключи используются в приложении, созданном по спецификациям ЕМУ 


ССО (Сопитоп Сохе ей 01$): 


" ключ Ка (АррИсамоп Сгурюотат Кеу) — используется для вычисления 
криптограмм приложения 


" ключ К! (МАС Кеу) — применяется для вычисления подписи данных 
(Меззасе Аифепйсаноп Соде — МАС) в командах скрипт-процессинга 


" ключ Кс (Епарбешаейе Кеу) — используется для зашифрования 
конфиденциальных данных в командах скрипт-процессинга 


Эмитент хранит только мастер-ключи симметричного криптографического 
алгоритма, которые в процессе персонализации карты преобразуются 
(ливерсифицируются) в уникальные ключи платежного приложения 
(диверсификация  мастер-ключа эмитента может быть выполнена 
несколькими способами с использованием АррИсавоп РАМ и АррИсаНоп 
РАМ бедаепсе МапоБей. ’Таким образом, каждое платежное приложение 
использует для криптографических операций набор уникальных ключей. 
Более того, уникальный ключ платежного приложения диверсифицируется 
для каждой транзакции в сессионный ключ. Для получения сессионного 
ключа используется АррИсаноп 'Ттапзасвоп Сочииег (АТС) — счетчик, который 
увеличивается при выполнении каждой транзакции. 


В результате для каждой транзакции карта и эмитент используют уникальный 
ключ симметричного криптографического алгоритма, что значительно 
повыптает безопасность. 


Верификация владельца карты выполняется для того, чтобы установить факт 
идентичности лица, получившего карту от её эмитента (клиента банка), с 
лицом, совершающим по карте операцию. Ключевым объектом данных для 
верификации владельца карты является объект СаФоЧег Уеййсаноп Мефоа 
(СУМ) 1456 который хранится на карте. Этот объекг определяег список 
методов и условий верификации владельца карты. 


Одним из основных методов верификации владельца карты является 
процедура проверки РП\-кода. Проверка РИ\-кода хотя и является только 
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одним из возможных методов верификации, но получили распространение в 
силу своей надёжности и эффективности. 


Существует два различных метода офлайновой проверки РИ\-кода: 
" проверка РП\-кода, передаваемого на карту в открытом виде 
" проверка РИ\-кода, передаваемого на карту в зашифрованном виде 


Офлайновая проверка РИМ\М-кода всегда начинается с того, что терминал 
выдает команду СЕТ РАТА для получения объекта данных РПМ 'Ггу Соииег. 
Значение этого объекта — это количество оставшихся попыток ввода РП\- 
кода. Нсли у владельца карты еше остались попытки для ввода РИ\-кода, то 
терминал получает от владельца карты значение его РП\-кода (от 4-х до 12-ти 
цифр) и формирует из РИ\-кода РИМ-блок в 150 Еошпае 2, который 
представлен на рис. 3. 


2м РР РР |Р/ЕР/Е Р/ЕРИЕ | Р/Е Р/Е | РИЕ РЕ 


Формат 2 и 
т Цифры РИ\-кода Значение ЕЕ 
Количество цифр в Цифра Р!№\-кода (Р) или заполнитель 
РИМ-коде (от 4 до 12) (Е) - определяется длиной РИ\-кода 


Рис. 3.Р\-блок в 1$О Рошла+ 2. 


Нсли в СУМ указано, что РИ\М-код должен быть предъявлен в 
незатифрованном виде, то терминал передает на карту команду УЕВТЕУ, в 
поле данных которой содержится значение РИ\-блока в 150 Копа 2. Когла 
РИ\-код должен быть предъявлен в зашифрованном виде, то сначала 
терминал получает от карты случайное число с помощью команды СЕТ 
СНАШЕМСЕ, затем формирует сертификат РИУ\-кода, который содержит 
РИ\-блок и полученное случайное число, и зашифровывает сертификат на 
открытом ключе карты. Затифрованный сертификат РП\-кода подается на 
карту в качестве данных команды УЕКТВКУ. Карта сравнивает полученное 
значение РИ\-кода со значением, хранимым на карте (предварительно 
расппифровывая сертификат РИ\-кода на секретном ключе карты и проверяя 
сертификат, когда это необходимо). Если они совпадают, то проверка РПМ- 
кода считается выполненной успешно. Каждый раз, когда предъявлен 
неправильный РИМ-код, количество оставшихся попыток ввода РИМ\-кода 
уменышается на 1 (при достижении нуля РИУ\-код будет заблокирован). 


Онлайновая проверка РП\-кода никак не связана с картой. Устройство ввода 
РИ\-кода запраптивает РМ-код от владельца карты и затифровывает его по 
специальному алгоритму, обычно используя алгоритм ООКРТ (ОШепуе4 
Опюие Кеу Рег 'Тгапзасноп). Верификация владельца карты терминалом на 
этом завершается, поскольку значение РП\-кода проверяет эмитент, а не карта. 
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Процедуры управления рисками, выполняемые терминалом, являются 
элементом обеспечения безопасности платежных операций и включаю в себя 
три механизма борьбы с карточным мошенничеством: 


" контроль размера операций, выполненных по карте 
" случайный выбор транзакции для её онлайновой авторизации эмитентом 
" проверка офлайновой активности использования карты 


По мере выполнения процедур аутентификации карты, проверки 
ограничений на обработку транзакции, верификации владельца карты, 
управления рисками терминал формирует поле с набором признаков, 
информирующих о результатах проверок, выполняемых терминалом в 
процессе обработки транзакции, которое называется 'Тентипа|! УеййсаНоп 
Везайз (ТУК). После завершения всех процедур терминал выполняет анализ 
всех ситуаций, зафиксированных в ТУК. Целью такого анализа является 
выработка терминалом рекомендательного решения о том, каким образом с 
точки зрения терминала должна быть продолжена обработка транзакции. 
Возможны три решения терминала: 


" транзакция должна быть одобрена в офлайновом режиме 
" транзакция должна быть направлена для авторизации эмитенту 
" транзакция должна быть отклонена в офлайновом режиме 


Когда говорят о решении «с точки зрения терминала», то имеют в виду, что в 
действительности решение формируется на основе правил, определенных 
обслуживающим банком (платежной системой) и эмитентом карты. Для этого 
в спецификациях ЕМУ определены два множества объектов данных, которые 
называются [з5аег АсНоп Со4ез (ТАС) и 'Гегпиа! Асноп Со4ез (ГАС). В свою 
очередь, каждое из этих множеств состоит из трех объектов с суффиксами 
Оема, Опйпе и Оеёл. Таким образом, используются следующие объекты. 


ТАС-Оепа| ТАС-Оема! 
ТАС-Орйпе ТАС-Опйпе 
ТАС-Оево ТАС-ОеоЕ 


Каждый из этих объектов имеет тот же формат, что и ТУК. ТАС и ТАС не 
являются обязательными с точки зрения спецификаций ЕМУ. Но ведущие 
платежные системы требуют их присутствия на карте и в терминале. 


ТАС загружаются в терминал обслуживающим банком (например, \15а и 
МазегСа!А определяют обязательные 'ГАС для обслуживающих банков). Эти 
объекты зависят от типа терминала и от карточного продукта. ТАС 
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определяются эмитентом карты и заносятся на карту во время её 
персонализации. Эти объекты определяют политику эмитента в области 
обеспечения безопасности своих операций. Назначение объектов поясняется 
в нижеприведенной таблице (в этой таблице используется синоним 


словосочетания «обслуживающий банк» —эквайер). 


Объект 


1АС-БВета! 


1АС-Опте 


1АС-БеаиЕ 


ТАС- Бета! 


ТАС- Опте 


ТАС-БегаиЁ 


Хотя по умолчанию все биты объектов 'ТАС-ОпНпе и ТАС-ОеёяЕ равны 0, в 
то же время ЕМУСо настоятельно рекомендует, чтобы обслуживающий банк 


Эмитент 


Эмитент 


Эмитент 


Эквайер 


Эквайер 


Эквайер 


Источник Назначение 


Условия, при которых транзакция 
должна быть отвергнута 


Условия, при которых транзакция 
должна быть отправлена на 
авторизацию эмитенту 


Условия, при которых терминал, 
неспособный обслужить транзак- 
цию в опте, должен её 
отвергнуть 


Условия, при которых транзакция 
должна быть отвергнута 


Условия, при которых транзакция 
должна быть отправлена на 
авторизацию эмитенту 


Условия, при которых терминал, 
неспособный обслужить транзак- 
цию в опте, должен её 
отвергнуть 


определил по крайней мере следующие признаки: 


" невыполнена офлайновая аутентификация данных карты 
" офлайновая аутентификация данных карты провалилась 


Терминал формируег свое решение о способе обработки транзакции, 


По умолчанию 


Все нули 


Все единицы 


Все единицы 


Все нули 


Все нули 


Все нули 


сравнивая биты, установленные в ТУК, ГАС и ТАС, следующим образом. 


1. Нсли в `ГУЕ есть единичные биты и соответствующие им биты в 1АС- 
Оема и 'ГАС-Оепа! также установлены в 1', то транзакция должна быть 
отвергнута без попытки выполнения онлайновой авторизации. В 
противном случае, терминал переходит к шагу 2, если терминал способен 
выполнить транзакцию в опйпе, или к шагу 3, когда терминал работает 


только в ОЕ ше. 


1 "Г.е. результат операции побитового логического умножения ГУК и результата побитового 


логического сложения ГАС и ТАС не равен 0. 
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2. Когда в ТУК есть единичные биты и соответствующие им биты в 1АС- 
Опше и ТАС-ОпШпе также установлены в 1, терминал считает, что 
транзакцию нужно отправить на авторизацию эмитенту. В противном 
случае, терминал предлагает карте одобрить транзакцию в офлайновом 
режиме. 


3. Нели в ТУК есть единичные биты и соответствующие им биты в [АС- 
ОеёоЕ и 'ТАС-Оеай также установлены в 1, то терминал считает, что 
транзакция должна быть отклонена. В противном случае, терминал 
предлагает карте одобрить транзакцию в офлайновом режиме. 


Принятое решение о способе обработки транзакции терминал сообщает 
карте в первой команде СЕМЕКАТЕ АС. В первой команде СЕМЕКАТЕ АС 
терминал может запросить от карты формирование одной из следующих 
криптограмм. 


1. Криптограммы ААС (АррШсавоп Аяфеписавоп Сгурюстап?), если 
транзакция должна быть отвергнута без попытки выполнения онлайновой 
авторизации. 


2. Криптограммы АКОС (Аяфойганоп Кедиезе Стурюотапо), когда терминал 


принял решение отправить транзакцию на авторизацию эмитенту. 


3. Криптограммы ТС (Тгапзасноп Сегайсаке), если терминал предлагает карте 
одобрить транзакцию в офлайновом режиме 


Карта получает от терминала в команде СЕМЕКАТЕ АС не только тип 
транзакции, запрашиваемой терминалом, но и данные, которые необходимы 
карте для выполнения собственных процедур управления рисками. 'Терминал 
узнает о том, какие данные требуются карте для выполнения процедур 
управления рисками и вычисления криптограммы через списки объектов 
данных, которые описаны в следующем разделе. 


Важная роль в процессе обработки транзакции отводится карте, которой 
эмитентом делегируются функции, связанные с принятием решения о 
способе завершения ‘транзакции. Карта, как и терминал, выполняет 
собственные процедуры управления рисками (Саг4 К15К Мапасетепе — СЕМ). 
На основе выполненных проверок карта проводит анализ полученных 
результатов и выносит своё решение (точнее, решение эмитента) о способе 
завершения транзакции. 


По аналогии с терминалом результаты своих проверок карта записывает в 
элемент данных, который называется Саг4 Уеййсачоп Везайз (СУК). Этот 
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элемент данных используется только картой (и эмитентом!) для принятия 
решений по результатам обработки транзакций. Важное отличие СУЁ от ТУК 
состоит в том, что в СУК часто хранится не только информация о текущем 
состоянии, но и часть истории, связанной с использованием карты, которая 
может потребоваться эмитенту. 


Выполняемые картой процедуры управления рисками МОЖНО Разделить по 
следующим ‘типам: 


" определение статуса проверки РИ\-кода в о ше 
" анализ результатов выполнения предыдущей транзакции 


" проверка офлайновых лимитов, ограничивающих количество последова- 
тельно выполненных картой офлайновых транзакций 


" проверка офлайновых лимитов, ограничивающих объем средств, 
потраченных в последовательно выполненных картой офлайновых 
транзакциях 


ы проверка статуса и результата выполнения команд скрипт-процессинг а. 


" проверка специальных условий обслуживания карты (признаков, которые 
сигнализируют о необходимости выполнения текущей транзакции в 
опНпе, определение факта того, что карта ещё ни разу не была 
авторизована эмитентом и т. п.) 


По мере выполнения процедур управления рисками карта формирует СУК. 
После завершения всех процедур карта выполняет анализ всех ситуаций, 
зафиксированных в СУК. Целью такого анализа является выработка картой 
решения об обработке транзакции. Решение формируется на основе правил, 
определенных эмитентом карты. Для этого в платежном приложении 
определено множество объектов данных, которые называются Саг4 15з9ег 
Асвоп Со4ез (СТАС) и состоит из трех объектов с суффиксами Репа], Оппе 
и еиь т.е. СТАС-Оема СТАС-Оше и СТАС-Ое ая? 


Каждый из объектов САС имеет формат, похожий на формат СУК. Как 
обсуждалось ранее, в СУЁК хранится некоторая информация о текущем 
состоянии, которая не используется в выработке решений картой. В связи с 
этим в СТАС определены только биты СУБ, информирующие о результатах 


1 СУК передается эмитенту в качестве компонента объекта 15зиег АррЁсаноп Рава. 


2 Не все платежные приложения поддерживают логику Саг ЁВ15К Мапасеглепе с использованием 
СУВ и СГАС. Например, приложение \1за использует другой алгоритм, базирующийся на указании 
эмитентом признаков, определяющих решение карты, в специальных объектах, записываемых в 
платежное приложение во время его персонализации. Но для очень большого числа платежных 
приложений применяется логика СУЁ и СТАС. 
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выполнения предыдущих транзакций и исключительных ситуациях, зафикси- 
рованных для текущей транзакции.! 


Выработка картой решения об обработке транзакции включает следующие 
шаги. 


1. Нсли терминал запраптивает у карты криптограмму ААС, то карта не 
анализирует СУЁ и генерирует запраптиваемую криптограмму. 


2. Нсли терминал запраптивает у карты криптограмму АКОС, то действия 
карты зависят от типа терминала. Когда терминал способен выполнить 
транзакцию в опНпе, терминал соглашается с решением терминала и 
формирует криптограмму АКОС. В случае офлайнового терминала 
транзакция отвергается и формируется криптограмма ААС. 


3. Когла терминал запраптивает у карты криптограмму ТС, и в СУК 
установлены биты, которым найдено соответствие в САС-Оепар, 
транзакция отвергается, карта формируег криптограмму ААС и 
возврашает её терминалу. В противном случае карта переходит либо к 
шагу 4, если терминал способен выполнить транзакцию в опйпе, либо к 
шагу 5 — в противном случае. 


4. Карта проверяет, не соответствуют ли ненулевым битам в СУЁ биты, 
установленные в СТАС-Опйпе. Если такое соответствие найдено, то карта 
считает, что транзакция нужно отправить на авторизацию эмитенту, и 
формирует криптограмму АКОС. В противном случае карта считает, что 
транзакцию нужно одобрить в офлайновом режиме, и формирует 
криптограмму ТС. 


5. Если в СУЁ установлены биты, которым найдено соответствие в СТАС- 
ео, транзакция отвергается, и карта формирует криптограмму ААС. В 
противном случае карта предлагает одобрить транзакцию в офлайновом 


режиме, и формирует криптограмму ТС. 


Рассмотрим, каким образом эмитент может управлять решением карты об 
обработке транзакции с помошью признаков, установленных в СТАС, на 
примере офлайновых счетчиков. В большинстве платежных приложений 
существует два вида счетчиков: 


"= олнобайтный счетчик количества  послеловательных операций, 
выполненных в ОЁН ше (Сопзесануе ОЁНше 'Ггапзасвоп МатаБег — СОТМ) 


! Опять же, нет правил без исключений. Результат выполнения предыдущих транзакций может не 
учитываться (зависит от приложения). Но для некоторых платежных приложений (например, 
созданных в соответствии со спецификациями ЕМУ ССО) — это обязательное условие. 


2Т. е. результат операции побитового логического умножения СУЁ и СТАС не равен 0. 
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"= сумма всех последовательных платежных операций, выполненных в ОЙ ше 
(Сопзесивуе ОН те 'Ттапзасноп Атоипе— СОТА) 


Каждому из счетчиков соответствует два лимита, определяемых эмитентом: 
нижний лимит и верхний лимит. Карта устанавливает в СУЁК признаки 
превьшпения заданных лимитов. Любой из счетчиков может использоваться 
для ограничения объема средств, потраченных в последовательно 
выполненных картой офлайновых транзакциях. Например, эмитент хочет 
использовать для этой цели количество последовательных операций, 
выполненных в Оше, как это показано на рис. 4. 


З ® Транзакция выполняется в оп[пе на 
терминалах, способных выйти в опте 


® Транзакция должна быть отвергнута, 
если выход в опте невозможен 


Ее Е А ЕВ НЕЕ ЕЕ Верхний 
лимит 
® Транзакция выполняется в опйпе на 
терминалах, способных выйти в оп!пе 
® Транзакция одобряется в офлайновом 
режиме, если онлайновая операция 
невозможна р 
еь ини Нижний 
лимит 


® Транзакция выполняется в о те на 
любом терминале 


Счетчик 


Рис. 4. Типичное использование офлайнового счетчика. 


Догику ограничения последовательно выполненных картой офлайновых 
транзакций можно описать следующим образом: 


"=  ссли счетчик меныше или равен нижнему лимиту, то транзакция должна 
быть выполнена в ОН ше 


ы когда счетчик больше нижнего лимита, но не выше верхнег о лимита, 
транзакция должна аутентифицирована эмитентом на терминалах, 
которые способны выйти в опйпе, или должна быть одобрена в офлайно- 
вом режиме, если онлайновая операция невозможна" 


1 Потому что терминал работает ТОЛЬКО В оЁЙпе, или из-за того, что терминал не может в данный 


момент выполнить транзакцию в опШпе (апаЫе 10 со опйпе). 
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"= ссли счетчик превышает верхний лимит, то транзакция должна быть 
выполнена в опШпе на терминалах, которые способны выйти в опШпе, или 
должна быть отвергнута, если онлайновая операция невозможна 


Чтобы карта могла поддержать такую логику ограничения последовательно 
выполненных офлайновых транзакций, эмитент должен установить в СТАС- 
Оппе биты «Превышен нижний предел офлайновых транзакций» и «Превы- 
шен верхний предел офлайновых транзакций», а в САС-Оеа! —бит 
«Превьитен верхний предел офлайновых транзакций». 


Тогда, если терминал запрашивает криптограмму ТС, карта увеличивает 
значение счетчика на 1, сверяет его лимитами и устанавливает в СУК признак 
«Превышен нижний предел офлайновых транзакций», если счетчик больше 
нижнего предела, и признак «Превышен верхний предел офлайновых 
транзакций», если счетчик болыше верхнего лимита. Нсли в СУЁК не 
установлен ни один из признаков превышения лимита, то карта сформирует 
криптограмму ТС независимо от типа терминала. В случае установки в СУК. 
признака превышения нижнего лимита (но не верхнего) для онлайнового 
терминала будет найдено соответствие признаков в СУК и СТАС-Опйше, и 
карта вернег криптограмму АКОС, а для офлайнового ‘терминала — 
криптограмму ТС, поскольку в СТАС-Пеа признак «Превышен нижний 
предел офлайновых транзакций» не установлен. Наконец, если в СУК 
установлены оба признака превышения лимитов, то карта сформирует 
криптограмму АКОС для онлайнового терминала и криптограмму ААС для 
офлайнового терминала, поскольку в САС-ОеаЕ установлен признак 
«Превьштен верхний предел офлайновых транзакций». 


Действия, выполняемые обслуживающим банком или эмитентом, не должны 
описывалься в этом документе. Хотя бы потому, что эмулятор терминала СУ 
не предназначен для связи с обслуживающим банком и эмитентом. Однако, 
по многим причинам, которые будут объяснены позже, следует пояснить 
логику обработки транзакции в онлайновом режиме. Следует иметь в виду, 
что далее приведено самое общее описание, которое может быть не приме- 
нимо к ряду платежных приложений. 


Если карта в ответе на первую команду СЕМЕКАТЕ АС указывает, что 
транзакцию нужно отправить на авторизацию эмитенту, терминал передает 
хосту обслуживающего банка сообщение, которое содержит информацию, 
относящуюся к карте и результатам обработки транзакции. На основе этих 
данных хост обслуживающего банка формирует авторизационный запрос 
эмитенту (сообщение х100 стандарта 150 8583), содержащий такие данные: 


" криптограмма АКОС 


"_ информация о карте (РАМ, срок действия карты и т. п.) 
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" информация о терминале (идентификатор, тип и т. п.) 
" последовательный номер транзакции АТС 
" элемент [55аег Аяфепасачоп Рафа, сформированный картой 


При получении авторизационного запроса эмитент проверяет, является ли 
карта, по которой проводится операция, подлинной. Для этого эмитент 
вычисляет сессионный ключ генерации криптограммы, после чего использует 
его и данные транзакции для получения криптограммы. Полученная 
криптограмма сравнивается с предоставленным значением АКОС. Если 
значения совпадают, аутентификация карты считается завершенной успешно, 
а сама карта — подлинной. 


Далее эмитент проводит стандартные проверки (проверка активности карты, 
истории использования карты, отсутствия карты в списке заблокированных 
карт, наличие средств на карт-счете, и т. п.). 


Данные, получаемые эмитентом в авторизационном запросе, позволяют ему 
принять правильное решение по способу завершения текущей операции, 
повлиять на выполнение следующей транзакции и произвести коррекцию 
данных карты с помощью команд скрипт-процессинга и (или) элемента 


данных СагА Звава$ Орда (С$0). 


После принятия решения о результате операции эмитент генерирует элемент 
данных [5заег Аифепйсаноп Рав. Этот элемент содержит криптограмму 
эмитента АВРС, которая используются картой для аутентификации эмитента, 
и Сага Заз Ораме (С$0), который указывает, одобрена или отклонена 
транзакция эмитентом, а также определяет действия, которые с точки зрения 
эмитента должны быть выполнены картой. В авторизационный ответ 
обслуживающему банку (сообщение х100 стандарта 1$О 8583) помещается 
элемент данных [35иег Аифеписаной Ода, код авторизации эмитента, а также 
команды скрипт-процессинга, если они должны быть переданы карте.! 


Если терминал не получил авторизационный ответ или получил его слишком 
поздно, терминал продолжает обрабатывать транзакцию, считая, что запрос 
невозможно передать эмитенту (эта ситуация обычно называется «апаЫе 0 со 
опИпе»). В любом случае, терминал должен получить криптограмму 
приложения от карты с помощью второй команды СЕМЕКАТЕ АС. Однако, 
перед выполнением этой команды терминал должен передать карте команды 
критичного скрипт-процессинга, если они присутствуют в авторизационном 
ответе. 


Во второй команде СЕМЕКАТЕ АС терминал передает карте данные, 
полученные от эмитента (код авторизации эмитента, элемент [$заег 


1 Элементы данных СЗО и [5заег Аифепасаноп Оа не являются обязательными для платежного 
приложения. Для некоторых приложений обязательна только криптограмма эмитента. 
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Аифепасавоп Па)! и уточненные данные своих проверок (ГУЕВ). Во второй 
команде СЕМЕКАТЕ АСтерминал может запросить от карты формирование 
одной из слелующих криптограмм. 


1. Криптограммы ААС, если транзакция должна быть отклонена. 


2. Криптограммы ТС, если терминал считает, что транзакцию следует 
одобрить. 


Процесс принятия картой решения после получения второй команды 
СЕМЕКАТЕ АС включает следующие шаги. 


1. Нсли терминал запрапивает криптограмму ААС, то карта генерирует 
запрашиваемую криптограмму. 


2. Когла терминал информирует о ситуации «апаЫе 0 со опИпе», карта 
проверяет, не соответствуют ли ненулевым битам в СУЁК биты, 
установленные в СТАС-Оео. Если такое соответствие найдено, то 
транзакция отвергается, и карта формирует криптограмму ААС. В 
противном случае карта может одобрить транзакцию после проведения 
дополнительных проверок. 


3. Карта аутентифицирует эмитента (проверяет значение криптограммы 
АКБРС в элементе 155аег АиФепасавоп Па). Если аутентификация 
эмитента не выполнена, то обычно транзакция отвергается (формируется 


криптограмма ААС). 


4. Нсли аутентификация эмитента выполнена успешно, дальнейшие 
действия карты определяются выбором эмитента, который определен в 
Саша Зваваз Ор4ае (СЗО). Карта формирует криптограмму ТС или ААСв 
зависимости от решения эмитента об обработке транзакции, и выполняет 
действия, которые определил эмитент в СЗО (например, установку 
счетчика оставитихся предъявлений РП\-кола, сброс офлайновых 
счётчиков и т. п.). Кроме этого, карта сбрасывает признаки особых 
ситуаций, которые были зафиксированы при выполнении предыдущей 
или текущей транзакции. 


Решение карты, принятое при выполнении второй команды 
СЕМЕКАТЕ АС, является окончательным. 


После завершения второй команды СЕМЕКАТЕ АС терминал должен 
передать карте команды некритичного скриит-процессинга, если они 
присутствуют в авторизационном ответе. 


1! Если онлайновая обработка невозможна (ситуация «апаЫе ю со опНпе»), то терминал сообщает 
об этом через код авторизации эмитента (элемент [55иег Аафепйсаноп Ра при этом обнулен). 
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Интерес к бесконтактным картам МОЖНО объяснить несколькими их 
техническими преимуществами: 


"= удобство использования карты (карту не нужно передавать кассиру, 
правильно ориентировать и вставлять в прорезь ридера, даже можно не 
вытаскивать из бумажника!') 


ы более высокая скорость выполнения транзакции 


м более высокая надежность использования карт и терминалов — Из-за 
отсутствия механического контакта карты и терминала обеспечивается 
более низкий уровень их физическог о износа 


м лучтпая защищенность бесконтактг ных терминалов от случаев вандализма 


Компания ЕМУСо уже давно прорабатывает вопрос о создании единого 
бесконтактного приложения ЕМУ СогиасЧез$ АррИсавоп — аналога 
приложения Соглтлоп Раутепе АррИсавоп (СРА) для контактных карт. Однако 
компания ЕМУСо не торопится с разработкой этого стандарта. Причина, 
озвучиваемая ЕМУСо, — недостаток опыта использования бесконтактных 
карт. Каждый тод проводится внутреннее обсуждение вопроса о 
целесообразности разработки стандарта, но положительного решения до сих 
пор нет. Появление стандарта на единое бесконтактное приложение в 
булущем не совсем очевидно. Поэтому ЕМУСо, предваряя появление такого 
стандарта, разработала спецификацию ЕМУ Сошас4езз бресаНсаНоп$ Юг 
Рауплепе Зузетлз — Каму Роше бресйсавоп (в дальнейшем будем для краткости 
называть его Нашу Рош ЗрессаНоп), решающую ряд вопросов. 


‘Этот стандарт определяег общую схему обработки транзакции по 
бесконтактной карте на стороне терминала (Каму Рош и достаточно 
подробно останавливается на описании процедур, предшествующих выбору 
приложения. На рис. 5 показана общая схема обработки транзакции в 
бесконтактном режиме. Не останавливаясь на деталях обработки отметим, что 
после предварительной обработки и активации протокола терминал начинает 
процедуру выбора бесконтактного приложения. Если терминал поддерживает 
единственное бесконтактное приложение, то он сразу выбирает это 
приложение с помощью команды ЗЕГЕСТ. Иначе, терминал выбирает 
приложение РРЗЕ (Рхгохиайу Рауплепе Зуует Епуйопилеп, которое имеет 
идентификатор 2РАУ.5 У5.ОШЕО1, и получает в ответ объекг НСТ, который 
содержит информацию о бесконтактных приложениях на карте. Далее 


1 Хотя идея о том, что карту можно не вытаскивать из бумажника, до сих переходит ИЗ КНИГИ В 
книгу, из статьи в статью, она трудноосуществима. Во-первых, хороший бумажник значительно 
снижает возможность распознавания карты терминалом из-за снижения мощности сигнала. Во- 
вторых, если в бумажнике есть другие бесконтактные карты, терминал скорее всего будет 
неспособен распознать карту из-за возникающих коллизий. 
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ОСНОВНЫЕ ПОНЯТИЯ 


терминал определяет, какие из поддерживаемых им приложений находятся на 
карте, локализует приложение с наивысшим приоритетом и второй командой 
ЗЕГЕСТ выбирает его. 


Терминал 


_Епугу РопЕ 


Предварительная обработка 


Активация протокола Платежная карта 


ЗЕГЕСТ РР$Е ® Возвращает в ответ на команду 
ЗЕТЕСТ РР5Е информацию о бес- 
РРЗЕ ЕС! контактных платежных приложе- 
Выбор платежного приложения ниях на карте (РРЗЕ ЕС!) 


ЗЕКЕСТ АЮ 
» Возвращает в ответ на команду 
—=—__________  ЗНЕСГ информацию о платежном 


ыы приложении (ЕС!) 


Активация ядра платежного 
приложения 


» Выполняет процедуры управления 
рисками, оценивает результаты и 
сообщает терминалу о своем 


СЕТ РКОСЕЗ$1М6 ОРТОМ5 


Обработка, выполняемая ядром Результат решении об обработке транзакции 
платежного приложения ВЕАО ВЕСОВО 
* Предоставляет данные приложе- 
ния из указанной записи 
Данные у 


Обработка результата 


О НИПЯРЕНЕС | 


3 эинанонлнеда| 


г1вниби ВИПУРЕНЕСЧ | 
12139иАЕэЭа иозАЧ 


иижэд ианизелноя 


внаномяцк 


Рис. 5. Обработка транзакции в бесконтактном режиме. 


24 


После выбора приложения происходит активация ядра, соответствующего 
приложению, которому Епму Роше терминала передает управление. Ядро 
завершает обработку формированием результата для Начу Роше. Возможные 
результаты обработки ядра — отклонение транзакции или одобрение в 
офлайновом режиме, направление транзакции для авторизации эмитенту, 
требование переключения в контактный режим и т. п. 


Одна из основных особенностей работы в бесконтактном режиме состоит в 
том, что обычно транзакция выполняется за одно прикосновение к терми- 
налу/ Кроме того, требуется, чтобы время нахождения карты в зоне 
считывания терминала было минимальным. Например, МазегСа1А настаивает 
на том, чтобы карта и терминал успели обменяться данными за 150 мсек (хотя 
сам эти требования и нарушает). В результате реализация бесконтактной 
транзакции в платежном приложении характеризуется следующими 
особенностями: 


" дляверификации владельца карты не может использоваться метод офлай- 
новой проверки РП\-кода? 


ы процедуры управления рисками, выполняемые терминалом, учитывают, 
что транзакция выполняется в бесконтактг НОМ режиме 


" вслучае онлайновой авторизации транзакции ответ эмитента не проверя- 
ется картой, команды скрипт-процессинга не выполняются (карта уже 
недоступна для терминала), а также отсутствует возможность выполнения 
действий, определяемых эмитентом в С$0 (например, установки счетчика 
предъявлений РИ\-кола, сброса офлайновых счётчиков и т. п.) 


" набор команд, используемых терминалом (ядром обработки приложения) 
для выполнения транзакции, обычно минимизируется, чтобы уменьшить 
время нахождения карты в зоне считывания терминала? 


| Ряд платежных систем (например, АтЕх) пошел по пути реализации транзакции за два прикосно- 
вения к терминалу. Второе прикосновение нужно после поступления отвега эмитента для его 
обработки. В этом случае бесконтактная обработка практически не отличается от контактной. 
'Такой метод не только неудобен Аля владельца карты, но и замедляег оплату товаров (услуг). 
Поэтому большинство платежных систем всё же используют единственное прикосновение. Этот 
метод и описывается далее. 


2 Офлайновая проверки РИ\-кода нежелательна по многим причинам. Во-первых, это небезопасно. 
Во-вторых, неудобно для владельца карты. Недаром, общая черта спецификаций бесконтактных 
приложений — отказ от предъявления РП\-кода в оЁЙште. Бесконтактные приложения используют 
два метода верификации — предъявление РИ\-кода в опНпе (при направлении транзакции для 
авторизации эмитенту) и подпись (в офлайновом режиме). 


3 Например, в ряде платежных приложений не используется команда СЕМЕКАТЕ АС, а данные, 
необходимые для одобрения транзакции эмитентом (криптограмма и другие параметры транз- 
акции), предоставляются терминалу в команде СЕТ РКОСЕ$$ МС ОРТОМ$. 
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Верификация владельца бесконтактной карты ограничивается несколькими 
методами: 


" проверка зашифрованного РИМ\-кода, выполняемая эмитентом (онлайно- 
вый РИ\-код) 


ы получение подписи владельца карты 


" верификация владельца карты не требуется (актуально в ряде случаев, 
когла сумма транзакции мала или необходимо обеспечить высокую 
скорость платежей) 


Кроме того, для мобильного устройства существует особый случай верифика- 
ции. Мобильное устройство может сообщить терминалу, что верификация 
владельца карты уже выполнена (на устройстве введен РИ\-код или предъяв- 
лен отпечаток пальца). 


Необходимо отметить, что для выбора метода верификации бесконтактная 
карта может не использовать СУМ 145% определяющий список методов и 
условий верификации владельца карты для контактного режима. Для целого 
ряла приложений используются другие объекты, которые определяют выбор 
метода верификации для бесконтактного режима. 


Процедуры управления рисками, выполняемые терминалом в бесконтактном 
режиме, достаточно просты. Во-первых, терминал должен сравнить сумму 
транзакции с пороговой суммой Сошас@езз Ттапзасной Гл. Нсли сумма 
транзакции превышает это значение, то бесконтактная транзакция не 
выполняется. Во-вторых, терминал сравнивает сумму транзакции с пороговой 
суммой СУМ КедашеЯ Глой. Когла сумма транзакции превьшпает это 
пороговое значение, терминал считает, что должна быль выполнена 
верификация владельца карты. 


Обычно, после этого терминал выдает команду СЕТ РКОСЕ$$ ПМС 
ОРТОХ$, с которой передаются данные, необходимые карте для принятия 
решения о способе обработки транзакции. Эти данные определяются 
списком РООГ, и определяют не только параметры транзакции, но и 
возможности терминала, а также результат предварительной обработки 
терминалом транзакции в бесконтактном режиме. 


Карта выполняет процедуры управления рисками и формирует СУЁК. При 
установке отдельных битов СУЁ учитываются признаки особых ситуаций, 
возникших при обработке предыдущей транзакции в контактном режиме 
(признаки особых ситуаций в бесконтактном режиме обычно не устанавли- 
ваются). 
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После завершения всех процедур карта принимает решение относительно 
завершения транзакции в соответствии с массивом СТАС!. Может быть 
приняг о одно из следующих решений: 


" транзакция одобряется в офлайновом режиме 

= требуется онлайновая авторизация транзакции эмитентом 
" транзакция должна быть отклонена 

" требуется переключение в контактный режим 


Последнее решение карта может принять в том случае, когда из-за целого ряда 
факторов выполнение транзакции в бесконтактном режиме невозможно (или 
нежелательно). Но решение о переключении в контактный режим прини- 
мается только в том случае, если ли терминал поддерживает контактный 
режим (в противном случае транзакция отклоняется). ’Таким образом, 
решение платежного приложения всегла согласовано с возможностями 
терминала и является окончательным. 


В зависимости от принятого решения карта может предоставить разные 
данные. Единственный элемент, который всегда входит в состав возвращае- 
мых данных, информирует терминал о выборе карты. Если карта возвращает 
криптограмму транзакции, то предоставляются также и другие данные, 
которые могут потребоваться терминалу для продолжения обработки 
(например, для формирования авторизационного запроса эмитенту). Среди 
этих данных присутствует элемент АррЁсаноп Ее Госабох (АНГ), содержащий 
ссылки на данные, которые терминал должен прочитать, чтобы успешно 
выполнить транзакцию. 


После чтения данных, определяемых АНГ, с помошью команды 
ВЕАО ВЕСОКО обработка ядра завершается формированием результата. 
Начиная с этого момента времени, карта уже не нужна для дальнейшей 
обработки и может быть удалена из зоны считывания терминала. 


Дальнейшие действия терминала зависяг от результата обработки ядра. 
Возможны следующие варианты. 


1. Требуется переключение в контактный режим обработки. 'Терминал 
предпринимает попытку выполнить транзакцию в контактном режиме. 


2. Транзакция отклонена. 'Герминал заверптает обработку транзакции. 


! Следует иметь в виду, что СТАС для бесконтактного режима могут отличаться от СТАС, применяе- 
мых для обработки транзакции в контактном режиме. Или СТАС вообще не используются для 
бесконтактного режима. 
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Должна быть выполнена онлайновая обработка. 'Герминал запрашивает 
ввод РИ\-кода, если это требуется, формирует авторизационный запрос 
для эмитента и пересылает этот запрос хосту. Основное отличие онлайно- 
вой обработки транзакции в бесконтактном режиме заключается в том, 
что ответ эмитента проверяет не карта (она уже удалена), а терминал. 
Конечно, терминал не может выполнить аутентификацию эмитента. Его 
решение об обработке транзакции должно соответствовать выбору 
эмитента. 
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Возможности 


абочее место комплекса тестирования ЕСУ — это специальное устрой- 

ство чтения смарт-карт с установленной лицензионной картой и 

программа проверки платежной карты, которая может функциониро- 

вать только в том случае, если обнаружит подключенное специальное 
устройство чтения смарт-карт. К рабочему месту комплекса тестирования 
могут быть подключены и другие устройства чтения смарт-карт, но наличие 
специального устройства с установленной лицензионной картой обязатель- 
но. Это связано только с тем, что компания Скан Гек лицензирует использова- 
ние комплекса тестирования ЕСУ с помощью лицензионной карты. 


Все устройства чтения смарт-карт, с которыми работает комплекс тестирова- 
ния ЕСУ — это РС$С-устройства. РС$С (правильно РС/$С, но в России уже 
давно принято наименование РСЗС без слэша) — это сокращенное наименова- 
ние (Регзопа! Сотприег/ Этан Сага) спецификации Мсгозой для интеграции 
смарт-карт в среду персональных компьютеров. Масгозой имплементировал 
РС$С в ХЛпао\уз 200х/ХР (и даже сделал РС$С доступным в УЛи4о\у$ МТ/9х!. 
Интересно, что свободная реализация (Нее зоЁ\уаге) существует даже для 
Глпиах (а также других Оп) в виде РС/$ЗС Гше, а не совсем легальная версия 
РС/$С Тие существует даже для Мас ОЗ Х. 


Все эти рассуждения интересны, но программа проверки платежной карты 
функционирует только под управлением операционной системы \УЛа4охуз. 
Рекомендуется версия \УЛп4оууз 10, но в любом случае версия операционной 
системы должна быть не ниже УЛадохуз 2000/ХР. Любые версии программы 
под управлением Глпих (и других Оп!Х), а также Мас 0$, не планируются, и 
вряд ли будут когда-нибудь осуществлены. 


После запуска программа проверки платежной карты на экране дисплея 
персонального компьютера, функционирующего под управлением Лоу, 
появляется окно программы, которое выглядит так, как показано на рис. 6. 
Конечно, окно выглядит не совсем так (и даже совсем не так). Потому что на 
рисунке выделены группы управляющих элементов, с помощью которых 
осуществляется регулирование процессом исследования ЕМУ-приложения и 
наблюдение за ходом его выполнения. 
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г Проверка платежной карты 


Выбор платежного приложения Е транзакции 


Устройство АСЗ АСВ1281 15 Биа!Веадег СС.0 Операция | ' покупка товаров (услуг) 


Приложение НЕОН У Сумма [2 00 | № 
[8 | 


РА-код 


Параметры эмуляции онлайновой обработки 
Тип САС2 ТС (упавелю до опйпе) 


[Г] соА 


[`] отклонить в случае УпаБе №0 до Опйпе 


с50 00 82 00 00 721 
бери та нелли 8 


Ключи СА | ключей: 158 платежных систем: 16 


. найден файл А0782601ЕЕ.РиБс Кеуз.р\иЬ с ключами платежной системы, ЕО которой равен А0782601ЕЕР 
*. найден файл А100000003.РиЫс Кеуз.р\/б с ключами платежной системы, ВЮ которой равен 4000000003 
* найден файл А100000004.РиЫ с Кеуз.р\мЬ с ключами платежной системы, ВО которой равен 4000000004 
* найден файл В012345678.РиБс Кеуз.р\и6 с ключами платежной системы, ВО которой равен 8012345678 
+ найден файл В112345678.РИЫ с Кеуз.р\ми6 с ключами платежной системы, В которой равен 8012345678 
* найден файл Е000008АС2.РИЫс Кеуз.ру/6 с ключами платежной системы, В которой равен Е000008АС2 
* найден файл Е74С696361.РиЫс Кеуз.р\"6 с ключами платежной системы, ЕО которой равен Е74С696361 

* обнаружено файлов с информацией о ключах платежных систем: 19 

+ количество платежных систем: 16 

* спределено публичных ключей платежных систем: 158 


Выполняется автоматическое удаление файпов с устаревшими протоколами функционирования из текущего каталога 
программы: 

* время актуальности протоколов: 26 час 

. количество файлов до удапения: 5 

* количество удаленных файлов: 4 

* количество файлов после удаления: 1 


У“ 
енг. аи. —>— 8 И. 


Рис. 6. Главное окно программы проверки платежной карты. 


На рисунке выделены следующие группы управляющих элементов, 
объединённых по функциональным признакам. 


1. Выбор платежного приложения, исследование которого должно быть 
выполнено. 


2. Определение параметров и возможностей терминала по обработке 
платежной транзакции. 
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3. Определение ключей терминала, необходимых для обработки транз- 
акции, а также ключей, которые требуются эмулятору терминала для 
моделирования онлайновой обработки. 


4. Основные параметры платежной транзакции и, возможно, персональная 
идентификация владельца карты. 


5. Параметры и особенности эмуляции онлайновой обработки. 


6. Дополнительные проверки, которые должны быть выполнены для карты 
или платежного приложения. 


7. Журнал событий (протокол), происходящих в процессе функционирова- 
ния комплекса тестирования, а также кнопки для управления журналом. 


8. Кнопки управления комплексом тестирования. 


Далее подробно рассматриваются возможности программы в соответствии с 
выделенными группами управляющих элементов. Это необходимо для того, 
чтобы пользователь смог понять, какие возможности доступны при анализе 
ЕМУ-приложения. Хотя программа проверки платежной карты и 
обстоятельно «документирована» (при наведении курсора мыши на любой 
управляющий элемент отображается подсказка, которая служит 
дополнительным средством обучения пользователя), но это не означает, что 
все возможности будут прозрачны для пользователя и он поймет логику 
разработчика. 


Одна из основных проблем, возникающих при анализе карты, состоит в том, 
чтобы определить, какие платежные приложения есть на карте. Как уже 
говорилось ранее, для РО$-терминала существует два метода выбора 
приложения: прямой выбор и выбор из списка (РЗЕ или РРЗН). Эмулятор 
терминала позволяет сделать то же самое, но с некоторыми дополнительными 
возможностями. Определение параметров для выбора анализируемого 
платежного приложения иллюстрируется с помощью рис. 7. 


Но сначала нужно выбрать РСЗС-устройство, в которое будет установлена 
исследуемая карта. Для этого служит сопаБо-Бох!, который содержит список 
всех устройств чтения смарт-карт, подключённых к компьютеру. Список 
устройств создается при запуске программы проверки платежной карты. Нсли 
новое РС$С-устройство подключается динамически в процессе функциони- 
рования, то достаточно построить список устройств заново. 


1 СотБо-Бох — это элемент управления, представляющий собой комбинацию списка элементов и 
строки редактирования. В дальнейшем такой элемент управления будет называться соппЬо-Бох, 
потому что длЯ ТТ-специалистов перевод может привести к неправильному толкованию термина. 
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ЖАНА 1$ Оца! Веадег СС 0 у 


1$ Оца] Веад 


АС АА 1281 1$ Виа! бк РСС 0 
построить список устройств заново 


2000008АС25445 (РаусоВМ) 


8 Проверка платежной карты 


Выбор платежного приложения 


Устройство [АСЗ АСВ1281 15 Руа! Веадег СС 0 
Приложение |А0000000041010 (МазцегСага Сгеай огреь® \ те ее Мег) 
«о ОСНО Матис Сити 

Е — А0000000050001 (Маз{егСага Маез!го ЦК) 
р ии. _ А00000002501 (Атепсап Ехргезз) 
А0000001523010 (О5соуег) 


А0000000421010 (СВ Сгед/Оебй сагд) 
А0000000422010 (СВ еб сага) 


А0000000651010 (СВ) 

А000000333010101 (УпюпРау Оеёй) 
А000000333010102 (ЦпюпРау Сгедй) 
А000000333010103 (УпюпРау Яцаз! Сгедй) 
А000000333010106 (УпюпРау Еесгопю Сазп) 


Приложение Маз!егСага у 
Особенности приложения неизвестны 
Прннию РаусоВМ 


?ри же ‚ Маз{егСага 
припамнниь СРА 
Приложение МИР 
Приложение МЗА 


Приложение РИВЕ 


А0000006582010 (МИР Оевё и Ргераю ОеБ\) 
А0000006582099 (МИР Оев& и Ргераю ОеБЁ (сопё 
А0000006581010 (МИР Сгедй) 

А0000006581099 (МИР Сгедй (сопас#ез$)) 

Из списка приложений-кандидатов 

Явное определение приложения 


Рис. 7. Выбор устройства и платежного приложения. 


Применяемый метод выбора анализируемого платежного приложения 
указывается параметрами, которые определяются с помощью оставшихся 
управляющих элементов. 


Во-первых, можно явно указать, что на карте должно быть выбрано 
приложение с заданным идентификатором (АПЭ). Для этого в сотБо-Бох 
«Приложение» выбирается строка с одним из стандартных АТО, соответст- 
вующим платежному приложению. 
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Во-вторых, можно указать, что должен быть построен список приложений- 
кандидатов и анализируемое приложение должно быть выбрано из этого 
списка. Список приложений- кандидатов строится следующим образом: 


" делается попытка отыскать на карте все приложения, АП) которых 
начинается с ВП)! платежных систем, перечисленных в списке сопаро-Бох 


" любое найденное приложение проверяется и устанавливается, является ли 
оно платежным? 


"= ссли приложение является платежным, то оно заносится в список 
приложений- кандидатов 


После завершения процедуры построения списка приложений- кандидатов 
пользователю предлагается выбрать исследуемое приложение из списка, как 
это показано на рис. 8. 


Выбор платежного приложения из списка кандидатов х 


Требуется выбор платежного приложения из списка приложений- 
кандидатов, построенного с использованием процедуры прямого вы- 
бора (путем поиска платежных приложений на карте по ВЮ). Список 
содержит несколько платежных приложений, которые могут быть об- 
работаны. Выберите для обработки одно из платежных приложений, 
приведенных в списке, укажите тип приложения и нажмите кнопку 
«Выбрать приложение». 


Описание 


А00000060041010 маз{егсага п{е 3! 


А0000000048002 Мазегсага ю{егпабопа! 


ЕЕК ЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЙЬЙ 
Тип приложения Приложение Маз{егСага У 


сть вевьть 


Рис. 8. Выбор приложения из списка приложений-кандидатов. 


1 ВШ — это первые пять байт АШО, которые назначаются платежной системе и однозначно её 
идентифицируют. Например, для МазегСа!4 назначен ВП) в виде А000000004 и АТФ всех карточ- 
ных продуктов МазегСагА должны начинаться с этого ВТО. 


2 Не все приложения на карте с ВТО платежной системы обязательно являются платежными. На 
карте могут существовать специальные сервисные приложения, которые относятся к платежной 
системе, но не могут использоваться терминалом для проведения транзакции. 
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В-третьих, интересующее приложение может быть определено явно. Для 
этого нужно в списке сотБо-Бох выбрать строку «Явное определение 
приложения», после чего в элементе редактирования «АП» ввести АШ 
приложения.! В этом случае может потребоваться выбрать тип приложения из 
списка сопаБо-Бох «Гип» 


Наконец, приложение может быть выбрано из списка Р$ЗЕ, (для контактного 
режима) или списка РРЗЕ, (для бесконтактного режима), если они есть на 
карте. В этом случае окончательный выбор приложения остается за пользова- 
телем. Он должен выбрать анализируемое приложение из списка, который 
будет отображен на экране (см. рис. 8). 


Для выполнения транзакции эмулятор терминала должен быть настроен 
соответствующим образом. Дело в том, что выполнение транзакции зависит 
от типа и возможностей терминала, политики эквайера в области безопас- 
ности платежных операций, и еще многих других параметров, которые в 
реальный терминал обычно загружает обслуживающий банк. Ддя эмулятора 
терминала все эти параметры могут меняться динамически перед выполне- 
нием транзакции, что позволяет проверять различные варианты поведения 
платежных приложений. 


Определение парамегров терминала демонстрируегся с помошью рис. 9. 
Пользователь можег определить следующее. 


"= Тип терминала, его возможности, а также дополнительные возможности, 
которые определяют физические особенности РОб-терминала и типы 
разрешенных транзакций. 


"= Условия принятия решения об обработке транзакции, которые устанав- 
ливаются для терминала в виде 'Гегилла! Асвоп Со4ез (ГАС). 


" Страну, в которой расположен терминал (платежное приложение может 
быть настроено на принятие решения об обработке транзакции в 
зависимости от того, является ли транзакция внутренней или междуна- 
родной). 


"= _ Параметры управления рисками терминала для контактных транзакций. 


" Параметры управления рисками для бесконтактных транзакций, которые 
обычно зависят от платежной системы. 


| Элемент редактирования «АШ» используется только при ЯВНОМ определении приложения. Во 
всех остальных случаях он недоступен для ввода и на его содержимое можно не обращать 


внимания. 
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Тип и возможности терминала 


Тил терминала 
ЕпукоптепЕ 


Установка ТАС платежной системы 


Сара у: 


Сопгойед Ву: 


Тегтипа! Асёюп Содез (ТАС) загружаются в терминал 
эквайером и определяют его политику в области безо- 


Возможности терминала 
Г] мапоа! кеу епху 


И мадпевс заре 
И сомассс 


Дополнительные возможности 

Тгапзасвоп Туре Оа!а при 
И митепс кеуз 
С Арва кеуз 
С соттапё кеуз 
[Я Еипсбоп кеуз 


Параметры терминала 
Свойства 22 (60788: 6900904010) 


тк по повыты езныю 


Страна Российская Федерация 
Риски 1000.00 (20: 500.00: 60) Е». 


Настройка бесконтактного режима 


пасности платежных операций. ТАС задают условия, 
при которых выполняются следующие действия: 
‚ ТАС-Оепа! - транзакция отклоняется 
* ТАС-Оппе — транзакция должна быть отправлена 
на авторизацию эмитенту 
* ТАС-Бе!аи( — транзакция отклоняется, если терми- 
нал не способен обслужить транзакцию в оппе 
Выберите устанавливаемый ТАС и определите прове 
ряемые признаки. Значение ТАС может быть также за 
дано в шестнадцатеричном виде (пять байт). Пос: 
установки значения выбранного ТАС не забудьте 
жать кнопку «Применить». 


ТипТАС  |ТАС-Оепё! 

Значение | 001000 00 00 
| Сбросить Тм 
| Применить значение 


4) Ува, Маз!егСагд и некоторые ду 


тежные системы определяют 4 
ные ТАС для эквайеров. Эти объ 
сят от типа терминала и его 
тей. Поэтому введенные ТАС 
ся только в том случае, когда 
мо, и неизвестно значение ТАС 
ванное платежной системой. 


араметры управления рисками терминала 


Лимит суммы платежа в офлайновом режиме: (Е | 


Случайный выбор транзакции для онлайновой обработки 
Целевой процент для случайного выбора: 


Порог суммы для пристрастного выбора: 
Целевой проццент для пристрастного выбора: 166 | 


Рис. 9. Определение параметров терминала. 
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ВОЗМОЖНОСТИ 


Определение ключей 


На рис. 10 показаны средства комплекса тестирования, которые применяются 
для определения ключей. Эмулятор терминала использует публичные ключи 
платежных систем для выполнения транзакции. Ключи платежного прило- 
жения могут не использоваться (их применение опционально). 


Публичные ключи платежных систем х 


Любой публичный ВЗА-ключ центра сертификации (СА) имеет уникальный иденти- 
фикатор в виде ВЮ платежной системы и индекса ключа СА. В текущем каталоге 
обнаружены определения ключей для следующих платежных систем. 


Платежная система 
‚ Атепсап Ехргезз 
Азз0Сагюпе Вапсама Кабапа 
Аиз!гавап Раутет!$ Сеаппо Аззосабоп Ц 
Спта Цпюпрау Со. Ма 
ЕцгоРау 
СВ (Зарап Сгед& Вигеаи) 
ИНК и (егспапое Мебмогк Ма (ЦК) 


Ключи платежной системы: 
ВО платежной системы: 


Описание: 
Состояние файла ключей: 


АЕАОТ010Е884Е2824650Е76404707951А16ЕЕС... 
АЕ4В80230Е0ЕСВ1538Е975795А10840С396А53.. 
80С2С6Е2А6386933С017С2394968748С57ЕЗ89.. 
00Е543Е032517133ЕЕ28А4А11044867586300С... 
АА94А8С60А024Е98А56А27С09801020819563... 
С805АС27А5Е1Е889978С7С6479АЕ993АВЗ800Е... 
СЕ980ЕЕ08303727965ЕЕ7797723355Е0751С810... = 


Ключи терминала 


кпючей: 158 платежных систем: 15 | 
- Ключ Ка 


Ключи СА 


Ключи РА, 
Ключ К 


Рис. 10. Определение ключей. 
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Разберем, зачем терминалу нужны публичные ключи платежных систем 
(более точно — ключи центров сертификации платежных систем) для 
выполнения транзакции. Как уже описывалось ранее (см. раздел «Вопросы 
безопасности»), чтобы получить доступ к публичному ВЗА-ключу карты на 
первом этапе терминал должен восстановить публичный ключ эмитента из 
сертификата этого ключа, подписанного на секретном ключе центра 
сертификации (Сегайсаноп Аяфойб или СА). А зачем терминалу публичный 
ВЗА-ключ карты? Во-первых, для выполнения офлайновой аутентификации 
данных. Во-вторых, для заифрования РП\-кода, если применяется метод 
верификации владельца карты «Предъявление затифрованного РИМ\-кода 
карте». И отсутствие ключа центра сертификации платежной системы может 
повлиять (и очень значительно) на ход выполнения транзакции. 


В связи с этим, в комплексе тестирования ЕСУ существует база данных со 
всеми известными публичными ключами платежных систем. Но если даже 
какой-то платежной системы нет в базе, или для неё отсутствует нужный ключ, 
то это легко исправить. Предоставляется возможность создать новую 
платежную систему с определенным КТО, или заблокировать все ключи 
определённой платежной системы (заблокированные ключи не удаляются из 
базы данных, но становятся недоступными эмулятору терминала). Кроме того, 
для любой платежной системы может быть создан новый ключ или удален 
существующий. 


С ключами платежного приложения не так всё просто, как с публичными 
ключами платежных систем. Для выполнения транзакции они не нужны, но в 
определенных случаях могут потребоваться эмулятору терминала для 
выполнения слелующих функций: 


" проверки криптограммы транзакции (ААС, ГС или АКОС, сгенериро- 


ванной картой 


"= генерации криптограммы эмитента в ответ на запрос авторизации в случае 
эмуляции онлайновой обработки 


"= создания команд скрипт-процессинга, используемых эмитентом для 
модификации информации на карте (опять же, в случае эмуляции онлай- 
новой обработки) 


Хотя использование ключей платежного приложения в эмуляторе терминала 
заманчиво, но возможно не всегда — существует целый ряд ограничений. Во- 
первых, в эмуляторе реализованы только алгоритмы для приложения, создан- 
ного по спецификациям ЕМУ ССО (Сотилоп Соге Оеблиноп5). Во-вторых, 
сам процесс диверсификации ключей, выработки сессионных ключей и 
вычисления криптограмм, формирования команд скрипт-процессинга 
настолько многоэтапный и сложный, что для применения ключей платежного 
приложения в эмуляторе терминала нужна болыпая подготовка. Конечно, 
окончательное решение остается за пользователем комплекса тестирования. 
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Группа управляющих элементов для ввода параметров платежной транзакции 
включает следующие объекты: 


" _ сотБо-Бох для определения типа платежной операции (транзакции) 
"= сумму платежной операции 


"= сумму возврата наличными (используется только для покупки с возвратом 
наличными — сазБаск; во-всех остальных случаях должна быть равна 0) 


"  сотБо-Бох для определения валюты платежной операции 


Кроме того, к этой группе управляющих элементов относится также строка 
редактирования для ввода РП\-кода владельца карты. Значение, указанное в 
качестве РПМ-кода, используется только в том случае, когда в результате анали- 
за списка методов верификации владельца карты установлено, что требуется 
предъявление РП\-кода карте. Если РП\-код не задан и требуется его предъяв- 
ление карте, то считается, что владелец карты отказался от ввода РИ\-кода. 


Необходимо обратить внимание на слелующие особенности применения 
РИ\-кода эмулятором терминала. 


1. Для онлайновой проверки значение РП\-кода не используется, так как 
эмулятор терминала не формирует данные для эмитента. Всегда считается, 
что предъявлен верный РП\-код. 


2. Будьте осторожны и не забывайте, что РПУ\-код, подходящий для текущей 
карты, скорее всего будет неверен для слелующей карты. Поэтому не 
забывайте менять значение РИМ\-кода для каждой анализируемой карты. 
Рекомендуется после проверки очередной карты удалять значение в 
строке редактирования для ввода РП\-кода. 


На рис. 11 показано, каким образом определятся параметры для эмуляции 
онлайновой обработки в комплексе тестирования ЕСУ. 


Нужно сразу сказать, что онлайновая обработка моделируется только для 
контактного режима, так как в бесконтактном режиме эмулятор терминала 
всегда выполняет транзакцию за одно прикосновение к терминалу. После 
завершения работы с картой и получения от неё всех данных эмулятор 
считает, что обработка завершена. В реальном терминале анализируется ответ 
эмитента, принимается решение об одобрении или отклонении транзакции. 
Эти действия никогда не выполняются в эмуляторе терминала, потому что 
ничего нового для проверки платежного приложения они не дадут. 
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ВОЗМОЖНОСТИ 


х 


Определение Сага 54а4и$ Урдае (С5И) 


|ТС (ззиег Ампеписавоп Оа!а Мо! Ргезет!) О оо пор ирдае ое соищегз 


ТС (ззиег АМпепйсавюп Райеа) (О) 5е1 оНпе соиегз №0 иррег о!Ите втёз 
ТС (3зиег АМнепбсавоп Регогтед @®) везе! оМе соигцегз 10 2его 
ви (О Ада гапзасвоп 10 о пе соит{егз 
[] сгеаев бу ргоху ‘юге взиег 
[[) зе бо опйпе оп пех гапзасбоп 
Параметры эмуляции онлайновой обработки О Урдае РМ {гу соимег 
Тип САС2 тс (Ипаые 10 до опйле} Я РИ ку соимег 
О соА С сага вюск 
[] отклонить в случае Упаые № де Опте С] Аррвсабоп Бюск 


00 82 00 00 *) 


не используется % 
НЕЕ ЕКВ 3 


Формирование скрипта 


Формирование скрипта 


-процессинг присыла- 
в второй командой СЕМЕ- 


В ответе эмитента могут присутствовать команды скрипт-процессинга, предназ- 
наченные для карты. С помощью этих команд эмитент имеет возможность обно- 
вить параметры платежного приложения, разблокировать или изменить Р№\-код, 
разблокировать платежное приложение. Критичный скрипт-процессинг присылает- 
ся эмитентом в объекте стэгом 71 и выполняется перед второй командой СЕМЕ- 
ВАТЕ АС. Определите команды критичного скрипт-процессинга. 


№ Команда Объект Данные 
{#1 АРРИСАТЮМ ИМВЬОСК состояние 
{1 2 РИСНАМОЕ РН 1111 
{$} 3 РНИМвиОСК РН 
$} 4 РИТОАТА ВЕ30 02010600000000000002110С... 
$ $5 РУТОАТА 8235 0Е0101000Е11020002 
$} 6 РИТОАТА ВЕЗО 0=0106000100000000 


Рис. 11. Параметры эмуляции онлайновой обработки. 


Для контактного режима эмуляция онлайнового режима имеет смысл, 
поскольку работа с картой после получения от неё всех данных для 
формирования авторизационного запроса эмитенту ещё не завершена. В 
реальной жизни терминал передает хосту обслуживающего банка сообщение, 
которое содержит информацию о транзакции. На основе этих данных хост 
обслуживающего банка формирует авторизационный запрос (сообщение 
х100 стандарта [50 8583). 
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Но эмулятор терминала не предназначен для связи с обслуживающим банком 
и эмитентом. Никакие сообщения хосту обслуживающего банка или 
авторизационные запросы эмитенту не формируются. Вместо этого эмулятор 
может смоделировать различные варианты получения ответа эмитента (или 
его отсутствия). 


Основным параметром для эмуляции онлайновой обработки является моде- 
лируемая ситуация, выбираемая из списка вариантов, определяемых соппБо- 
Бох «Гин САС2». Из списка, определяемого этим элементом, выбирается 
один из следующих вариантов действий терминала при выполнении второй 


команды СЕМЕКАТЕ АС: 
"_ _ должна быть запрошена криптограмма ААС (отклонение транзакции) 


"=  запрашивается криптограмма ТС с моделированием ситуации «ОпаЫе ю 


20 Оппе» 


"  запрашивается криптограмма ГС (имитируется ситуация «Данные эмитен- 
та не предоставлены») 


"=  запрашивается криптограмма ТС (для платежного приложения моделиру- 
ется ситуация «Аутентификация эмитента не выполнена») 


"_ во второй команде СЕМЕКАТЕ АС запраитивается криптограмма ТС и 
предоставляются данные эмитента, которые позволяют платежному 
приложению успешно выполнить аутентификацию эмитента (для прило- 
жения моделируется полноценный ответ эмитента) 


Дальнейшее обсуждение особенностей перечисленных выше вариантов ещё 
предстоит, а пока нужно обсудить другие параметры эмуляции онлайнового 
режима. Сразу следует сказать, что эмуляция онлайнового режима была 
разработана для приложений, удовлетворяющих спецификациям ЕМУ ССО 
(Сопитоп Соге ОеЁН1о1п$). И для целого ряда платежных приложений 
параметры онлайнового режима (объекты данных) не используются (не 
применимы). 


Один из таких объектов данных — Саг ава Ораме (С$0), который 
указывает, одобрена или отклонена транзакция эмитентом, а также определяет 
действия, которые с точки зрения эмитента должны быть выполнены картой 
(см. рис. 11). Определение признаков в СЗО игнорируется, если хост эмитента 
не должен использовать СЗО для управления платежным приложением. 


Как показано на рис. 11, в комплексе тестирования ЕСУ также прелусмотрена 
возможность формирования команд критичного и некритичного скрипт- 


1 Имеется в виду тип запрашиваемой криптограммы во второй команде СЕМЕВАТЕ АС. Из даль- 
нейшего изложения будет ясно, что список определяет не только тип запрашиваемой кринто- 
граммы, но и различные варианты онлайновой обработки. 
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процессинга. Но команды скрипт-процессинга формируются в соответствии 
со спецификациями ЕМУ ССО. Дело втом, что эмитент при создании команд 
скрипт-процессинга использует алгоритм Зесиге Меззаоше. Основные цели 
Зесиге Меззасло — обеспечить целостность данных, предоставить возмож- 
ность аутентификации источника данных и гарантировать конфиденциаль- 
ность секретных данных. Алгоритм б5есиие Меззаоиае для приложения ЕМУ 
ССО реализован в соответствии с Зесиге Меззаотпе НогплаЕ 1, который описан 
в документе «ЕМУ. Пиеогие4 Сисий Сага бресйсаноп$ Юг Раутепе Зузвеплз. 
Воок 2. Зесииу ап4 Кеу Мапаоеплепе. Уегзюп 4.2. пе 2008». 


Из этого следует два важных вывода. Во-первых, если для анализируемого 
платежного приложения команды скриит-процессинга формируются не в 
соответствии с Зесиге Меззаое Рота 1, то средство определения команд 
скрипт-процессинга, предусмотренное в комплексе тестирования, использо- 
ваться не может. Во-вторых, как легко догадаться, для создания команд скрипт- 
процессинга эмулятору терминала требуются ключи платежного приложения 
(см. раздел «Определение ключей»). 


А теперь возвращаемся к обсуждению вариантов действий эмулятора терми- 
нала при выполнении второй команды СЕМЕКАТЕ АС. Как было описано 
выше, для эмуляции онлайновой обработки пользователь может выбрать 
один из пяти вариантов. Действия эмулятора терминала зависят от выбран- 
ного варианта. Но в любом случае, эмулятор выполняет следующее: 


" перед выполнением второй команды СЕМЕКАТЕ АС передает карте 
команды критичного скрипт-процессинга, если они определены 


" после выполнения второй команды СЕМЕКАТЕ АС посылает платеж- 
ному приложению команды критичного скрипт-процессинга, если он 
используется 


Остальные действия эмулятора терминала зависят от выбранного варианта 
развития событий. 


Отклонение транзакции. 


В этом случае действия эмулятора терминала совсем не интересны, так как 
платежное приложение игнорирует данные, предоставленные во второй 
команде СЕМЕКАТЕ АС, и всегла возвращает криптограмму ААС (отклоне- 
ние транзакции) 


Одобрение транзакции в ситуации «ОпаЫе ю го ОпШпе» 


Эмулятор терминала сообщает платежному приложению об этой ситуации во 
второй команде СЕМЕКАТЕ АС, запраитивая одобрение транзакции. Вместо 
данных эмитента обычно передаются нули. 
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Одобрение транзакции в ситуации «Данные эмитента не предо- 
ставлены» 


Мало чем отличается от ситуации «ОпаЫе © со Опйпе». Но есть отличия в 
данных, передаваемых платежному приложению во второй команде 
СЕМЕКАТЕ АС, в связи с чем поведение платежного приложения может 
отличалься. 


Одобрение транзакции и моделирование ситуации «Аутентификация 
эмитента не выполнена» 


Эмулятор терминала запрашивает одобрение транзакции во второй команде 
СЕМЕКАТЕ АС, передавая в качестве криптограммы эмитента случайное 
число (считается, что оно никогда не совпадет с криптограммой, которую 
должен сформировать эмитент в ответ на запрос авторизации). 


Одобрение транзакции с полной эмуляцией ответа эмитента 


Во второй команде СЕМЕКАТЕ АС требуется одобрение транзакции с 
предоставлением данных, которые позволяют платежному приложению 
успешно выполнить аутентификацию эмитента и выполнить действия, 
запрашиваемые эмитентом. Для этого варианта эмулятору терминала 
требуются ключи платежного приложения (см. раздел «Определение 
ключей»). 


Осталось только описать два переключателя, которые показаны на рис. 11. 
Переключатель «СОА» позволяет запросить от платежного приложения 
сертификат Зюпе@ Гупапие Аррйсаноп Га (используется для метода 
офлайновой аутентификации СОА), не только в первой, но и во второй 
команде СЕМЕКАТЕ АС. Хотя на первый взгляд эта возможность и кажется 
излишней, но получение сертификата метода СОА во второй команде 
СЕМЕКАТЕ АС определено спецификациями ЕМУ для особых случаев. 
Таким образом, переключатель «СОА» позволяет проверить, способно ли 
платежное приложение предоставить сертификат Зюпе4 Оупапис АррЁйсаноп 
аа во второй команде СЕМЕКАТЕ АС. 


Переключатель «Отклонить в случае ОпаЫе кю го ОпЙпе» отражает возмож- 
ность, которая доступна обслуживающему банку для настройки терминала, 
работающего только в онлайновом режиме. Для таких терминалов может 
быть определено, что в ситуации ЧпаЫе о со Оппе транзакция должна быть 
отклонена без анализа ГАС/ТАС. 
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Г руппа управляющих элементов, определяющих дополнительные проверки, 
которые ВЫПОЛНЯЮТСЯ В процессе анализа карты, позволяет осуществить 
следующие проверки: 


" проверку РЗЕ (Рауплепе Зумет Епушопилеп) 
" анализ РРЗЕ (Ргохнану Рауплепе Зузетл Епуополеп® 


"= отображение информации из журнала транзакций платежного приложе- 
ния, если он поддерживается 


" получение и анализ объектов по команде СЕТ РАТА 


Далее приводится краткое описание этих дополнительных возможностей по 
проверке платежного приложения и его среды. 


Проверка РЕ 


В контактном режиме для выбора платежного приложения может использо- 
ваться РЕ (Рауплепе Зузетл Епуйопилеп® и комплекс тестирования позволяет 
выполнить его проверку. В терминологии ЕМУ — это каталог, но на самом 
деле — это приложение с идентификатором 1РАУ.ЗУ$.ООЕ01. Эмулятор 
терминала сначала выбирает на карте приложение Р$Е, которое возвращает 
УНГ файла со списком приложений на карте. Затем последовательно с 
помощью команды КЕАО КЕСОВО читает записи этого файла и извлекает 
из них информацию о платёжных приложениях, присутствующих на карте. 
Анализ РЗЕ, никогда не выполняется в бесконтактном режиме обработки. 


Анализ РР$Е 


В бесконтактном режиме процедура выбора платежного приложения основа- 
на на использовании приложения РРЪЕ, (Ргохипиу Раугтепе Зузет Елушоп- 
плепб, которое имеет идентификатор 2РАУ.5У5.ОЮЕО. В ответ на команду 
ЗЕГЕСТ приложение РРЗЕ возвращает объект ЕСТ, содержащий информа- 
цию о бесконтактных приложениях на карте. Используя полученную инфор- 
мацию, эмулятор терминала проверяет список бесконтактных платёжных 
приложений, определённый в РРЗЕ. Анализ РРЗЕ никогда не выполняется в 
контактном режиме обработки. 


Отображение информации из журнала транзакций 


Ряд платежных приложений может иметь журнал транзакций — специальный 
файл, в котором регистрируются транзакции. Эмулятор терминала позволяет 
считать записи журнала транзакций и отобразить информацию из этих 
записей. Нужно иметь в виду, что журнал транзакций для любого платежного 
приложения является опциональным. 
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Получение объектов по команде СЕТ РАТА 


Но не все данные платежного приложения расположены в записях файлов 
(записи файлов считываются по команде КЕАО КЕСОКО). Некоторые 
данные хранятся в виде отдельных объектов и при необходимости терминал 
извлекает их с карты с помощью команды СЕТ РАТА. Например, 
офлайновая проверка РПМ-кода всегда начинается с того, что терминал выдает 
команду СЕТ АТА для получения объекта РИМ 'Тху Солищег. Значение этого 
объекта — это количество оставшихся попыток ввода РИ\-кода. 


Большинство объектов данных платежного приложения, считываемых с 
помощью команды СЕТ ЛАТА, для выполнения транзакции не нужны. 
Эмулятор терминала может считывать определенные объекты, чтобы инфор- 
мировать пользователя о том, почему карта приняла решение об обработке 
транзакции, отличающееся от решения терминала. Но эмулятор терминала 
никогда не считывает дополнительные, ненужные ему объекты, если не 
включён переключатель «Получение объектов по команде СЕТ РАТА». 
Установка этого переключателя заставляет эмулятор терминала считывать все 
известные ему объекты анализируемого платежного приложения. Информа- 
ция из считанных объектов проверяется и объясняется. 


Если включён переключатель «Получение объектов по команде СЕТ'РАТА», 
то может быть установлен и переключатель «Поиск неизвестных объектов», 
информирующий о том, что требуется поиск всех объектов платежного 
приложения (даже не определенных в спецификациях), которые могут быть 
получены с помощью команды СЕТ АТА. При установленном переключа- 
теле выполняется последовательное чтение всех объектов по тэгам, которые 
не определены в спецификациях анализируемого платежного приложения. 
Если тип платежного приложения не определен, то проверяется доступность 
всех объектов, кроме стандартных объектов ЕМУ. Таких объектов много 
(больше 1000), поэтому не рекомендуется без особой нужды использовать 
данную возможность (поиск объектов может занять несколько десятков 
секунд). При выполнении транзакции в бесконтактном режиме в болышинстве 
случаев установка этого переключателя игнорируется. 
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Журнал событий, зафиксированных в процессе работы комплекса тестирова- 
ния, — это основной источник информации о среде функционирования, 
результатах проверки карт, анализа данных и т. д. Журнал событий (протокол) 
отображается в отдельном окне программы и может быть просмотрен в 
любой момент работы с комплексом тестирования. Кроме того, протокол 
всегда сохраняется в текущем каталоге (каталоге, из которого запущена 
программа) в файле с именем Са Уеййсаноп Гос.х.у, где х — дата, а у— время 
создания файла с протоколом. 


Обычно, журнал содержит много данных. Чтобы облегчить навигацию и 
поиск нужной информации, существуют кнопки управления журналом, 
показанные на рис. 12. 


. . Две кнопки со стрелочками позволяют перейти в 
й у | | окне протокола к началу исследования карты с 
. платежным приложением. Например, предполо- 


жим, что в окне отображается фрагмент исследова- 
Рис. 12. Кнопки ния карты 3. Тогда нажатие кнопки со стрелкой вверх 
управления журналом. приведет к установке протокола в начало исследова- 
ния карты 3, повторное нажатие — к установке в 

начало исследования карты 2 и т. д. 


Аналогично, нажатие кнопки со стрелкой вниз приведет к установке 
протокола в начало исследования карты 4, повторное нажатие — к установке в 
начало исследования карты 5... 


Последняя кнопка используется для сохранения протокола в файле и одно- 
временной очистки окна протокола. Следует сразу сказать, что протокол в 
любом случае сохраняется в файле и обычно это делается в автоматическом 
режиме. Нажатие кнопки сохранения протокола приводит к следующему. 


" Все строки, представленные в окне протокола, записываются в файл с 
именем Сага Уеййсаноп Гос.х.у. Этот файл создается при запуске 
комплекса тестирования, и он всегла один (новый файл будет создан 
только при следующем запуске комплекса тестирования). 


"= _ Из окна протокола удаляются все строки (окно очищается). 


'Таким образом, кнопка сохранения протокола позволяет вывести из рассмот- 
рения информацию, если сейчас она болыше не нужна. Разумеется, эта 
информация не теряется и может быть проанализирована позже. 
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Кнопки управления 


Для управления комплексом тестирования ЕС\У предназначены кнопки, 
показанные на рис. 13. 


Информация о платежной карте 
Проверка персонализированной карты 


Ниже приведена итоговая информация об исследованной плате? 
писей файлов платежного приложения, значения объектов, пол 
ходе проверки платежной карты. 


Общая информация с карте и проверенном платежном приложении. 
* АТВ карты: 386Е00008031805580840С016Е0 133009000 
* карта была обработана в контактном режиме 
* АЮ платежного приложения (ОЕ Мате}: А0000000041010 
. данные из РС! платежного приложения: 
. Аррйса#оп ГабеЕ 40617374557243617264 «Маз{егСага» 
* Аррисавоп Рногбу пфка!юг: 01 
* Гапоцаде Рге{егепсе: 7275656Е «гиеп» 
Проверка карты начинается сразу после од Епну: ОВОА 
ное устройство чтения карт. Результаты пр › Токо Рапу Оа{з: 06430000303000 
повторить проверку карты удалите её из * Соигигу Соде: 0643 
. /пюуе еп бег аззюпед Бу Маз{егСага: 0000 
Параметры обработки для проверки * Оемке Туре: «00» (Сага) 
‚ текущее время: 17:48:24 13.02.2019 * Ргорпеагу Фа(а: 30 
‚ устройство чтения карт: Сетайо 058 $ 
* АЮ платежного приложения: А0000000 


Информация о платежном приложении, полученная при выполнении команды СЕТ РВОСЕ?З 
* тип платежного приложения: не явля 


* Аррёсавоп КМегспапде Ргойе: 3900 


* СОА зирропед 
Из устройства, которое используется для * Сагдпокег Мепйсавоп зирройед 
на карта. * Тегтюа! ВК Мападетеп! 10 Бе ре‘огтед 
* СВА зирроцед 


* АррЕсавбоп Рйе Госа{ог: 10020201180101002001010028010200 
* $Е12, гесогд 2, {№5 гесогд пуомед м ОБА 
* $213, гесога 1 
* $214, гесога 1 


БЕ: 3] 


| о Р Персонализация ||  Информаця ДЖ Исследование 


Опции функционирования 


Срок хранения протоколов 


[Г допускается нестрогое соответствие спецификациям ЕМУ 


[Г Полная трассировка выполняемых криптографических операций 
0 Полная трассировка обмена данными с картой 
С не издавать звуки при наступлении событий в программе 


Рис. 13. Кнопки управления комплексом тестирования. 
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При нажатии на эти кнопки комплекс тестирования информируется, что 
пользователь желает выполнить определенное действие, связанное с опреде- 
лением параметров функционирования, проверкой карты или просмотром 
параметров платежного приложения. Далее подробно объясняется, какие 
действия выполняются при нажатии кнопок управления. 


Опции 


Кнопка «Опции» позволяет настроить опции функционирования комплекса 
тестирования, показанные на рис. 13 в окне «Опции функционирования». 
Среди настраиваемых опций есть сервисные возможности (например, улале- 
ние устаревитих протоколов и запрет звуков при наступлении определенных 
событий), которые позволяют адаптироваль комплекс тестирования под 
требования пользователя и никак не влияют на выполнение проверки платеж- 
ных приложений. 


'Также присутствует довольно странная опция «Допускается неполное соответ- 
ствие спецификациям ЕМУ». На первый взгляд «вредная» возможность, но 
она позволяет продолжить проверку приложения, даже если уже обнаружены 
ошибки (например, это бывает полезно при проверке сертификатов ключей). 
Эту возможность не рекомендуется использовать неопытным пользователям, 
так как бывает достаточно трудно оценить, насколько то или иное несоот- 
ветствие влияет на дальнейший ход тестирования. 


Две оставшиеся возможности очень часто требуются при проверке платежно- 
го приложения. Во-первых, можно определить, что требуется полная трасси- 
ровка выполняемых криптографических операций. Во-вторых, может быть 
запротоколирован весь обмен комплекса тестирования с картой. 


Если эти возможности часто используются, то почему они являются опцио- 
нальными? Ответ на этот вопрос достаточно прост. И трассировка выполняе- 
мых криптографических операций, и трассировка обмена данными с картой 
приводит к тому, что протокол проверки платежного приложения становится 
очень большим. Именно поэтому протокол, приведенный в документе (см. 
главу «Приложения»), создан без использования этих опций. Во многих 
случаях, дополнительные данные об обмене с картой и криптографических 
операциях не нужны. Как только пользователь принимает решение, что ему 
потребуются эти дополнительные данные, он всегла может включить опции 
дополнительных трассировок. 


Когда определено, что выполнение криптографических операций должно 
быть занесено в протокол, то в журнале будет формироваться объяснение 
того, как комплекс тестирования реализует криптографические проверки. 
Например, на рис. 14 приведен фрагмент протокола с выполнением крипто- 
графической операции проверки сертификата публичного ключа эмитента. 
Для любой криптографической операции всегла приводятся исходные дан- 
ные, промежуточные результаты и результаты выполнения (проверки). 
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Криптографическая операция проверки сертификата публичного ключа эмитента. 
Исходные данные для операции: 
* экспонента публичного ключа СА: 03 
* модуль публичного ключа СА; 
В8 04 8А ВС 30 С9 00 97 63 36 54 ЗЕ ЗЕ 07 09 1С 
ЗЕ Е4 80 00 [8 20 ЕО 55 Е7 Е9Э 48 13 ЕВ 00 55 5В 
57 ЗРЕС АЗ 08 4А Еб 13 1А 65 10 66 СЕ [4 28 4Е 
ВЛ ЗВ 63 5Е ОО ОЕ Е4 01 76 08 ВЕ 04 В7ЕБ 1С 7В 
АС РЭАС 73 27 ОР АА ЗА А? 20 10 ОВ ЗВ 8Е 70 В2 
00 08 11 СВ 41 96 52 5Е АЗ 86 АС СЗ 3С 00 90 45 
75 91 64 69 С4 Е4 Е5 ЗЕ 8Е 1С 91 2С С6 18 СВ 22 
ООЕТ С3 56 8Е 90 02 2Е 6В ВА 77 02 02 Е4 522А 
20 06 23 01 80Е2 15 ВО 10 15 07ЕЕ 30 С9 0С АЗ 
10 02 7В ЗЕ ЕС СО ВЕ 83 ОЕ 30 52 СА ГЛ Е4 89 38 
С6 80 09 5А АС 91 В5ЕЗ 7Е 28 ВВ 49 ЕС ТЕ 05 97 
. зашифрованный сертификат ключа эмитента: 
20 8С 41 ЕС 26 54 76 24 ЭА 10 72 В8 79 Е1 61 4Е 
ЗА СЗ ВО РС ЛА ЕЕ С3 68 64 Е? 6А 81 6Е 85 Е7 ВО 
РА ЗС ВР 34 ВВ 6Е АС АО ОР 6В 90 07 30 С2 52 А2 
ЕС В5 35 Е? ЗС СЕ 65 АВЕС 07 9Е 95 83 В7 65 ВА 
С1 8 Е? 56 ВО В9 50 А7 7А Е9 56 1С 77 09 41 04 
В5 03 ЗВ 2В С7 11 ЛА 43 76 87 43 [5 50 ЗР 60 80 
ОО 17 59С [0 46 СВ В5 92 2С 4 65 7А 87 13 03 96 
С5 58 5В 95 60 А9Э 2В ЗВ 57 ЕО 23 96 01 А1 04 84 
ЕВ Е9 26 ЕЕ ЗС 41 ЗЕ 57 АЕ ВЕ 2Е 80 Е5 02 09 00 
2В 5Е 2Е ЛВ 79 В8 99 22 74 1Е 26 32 ЕЕ АЭЕЗ 07 
РЕ 7Е 27 35 ЗЕ 8Е 7С 77 ЕЕ ЗВ ЕС А9Э 2А АЗ В7 90 
Результаты криптографической операции проверки сертификата публичного ключа эмитента: 
* расшифрованный сертификат ключа эмитента: 
бА 02 53 45 26 ЕЁ 12 23 00 ЭА 6Е 01 01 90 01 Е2 
82 6Е 7С ЕЗ В5 ОР 5С ЕР 50 ЕС 40 25 72 ОЕ 70 ЕЕ 
87 ЕБ 09 7А 1С 40 ВЕ ОА 20 57 25 ВО АЗ Е4 ЕС 05 
60 В7 81 ОЕ Е1 78 71 93 2Е 86 89 50 АВ 4Ё А5 А4 
6С 5А ЕА 27 5С 60 60 04 7Е 23 08 ЕЗ ВО Е8 46 54 
ЕЯ ОС 28 Е3 СЗ 40 27 00 ЗВ Е7 РА 2А 7А 7Е ЗВ 97 
54 ВС 6Е 91 ОА АЗ 9С 5В 69 04 А7ТЕОЙ С1 94 07 27 
ЭЕ 6С 6СЕсС ВА 6Е 10 60 Вб 76 4Е 49 ЕЭ 25 90 Е7 
ЗВ ОВ Е8 АЭ ЗА ЕО 40 6С 82 15 11 76 ОЕ 59 ВЕ 89 
АТАВ 09 9А 60 38 44 ЕС 70 ВС Е4 ЭА 37 АБ С7 50 
ТЕ ОВ 62 89 77 59 А5 ЕО2Е 9С ЕЕ СА 54 67 31 ВС 
. проверяется хэш сертификата, для чего используются следующие дополнительные данные: 
. 155иег РуБс Кеу Кетатадег: 42149007 
* [5зцег РиБ с Кеу Ехропег": 03 


Рис. 14. 'Грассировка криптографических операций. 


Если задана трассировка обмена данными с картой, то в протокол будут 
помещаться информация о командах, передаваемые карте, и ответе, получен- 
ном от карты. На рис.15 приведен фрагмент протокола с включенной 
трассировкой обмена данными с картой (строки, поясняющие работу с 
картой, выделены красным цветом). Для любой команды отображается её 
кодировка, данные, передаваемые вместе с командой, а также данные, получен- 
ные от карты и байты состояния (код возврата карты). Следует иметь в виду, 
что трассировка действий с картой не зависит от любой другой трассировки. 
Поэтому в протоколе могут появляться избыточные данные (например, на 
рис. 15 ответ карты на команду СЕТ РКОСЕ$$ УС ОРТЮМ$ приведен в 
двух местах). 
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7. Выполнение команды СЕТ РКОСЕ$ЗЭИМС ОРТ!ОМ$ для инициирования транзакции и получения 
информации, необходимой для выполнения транзакции. 
* для инициирования транзакции никакие данные не нужны, поскольку не определен РОС\, 
и в качестве входных данных команды предоставляется объект Соттапа Тетра е (тег 83) 
с нулевой длиной 
. платежному приложению передается команда СЕТ РКОСЕ$З МС ОРТЮМ$ 


Действие с картой: 
. команда: 80 АЗ 00 00 
* длина данных для карты: 2 
- данные для карты: 83 00 
- код карты: 61 10 


Действие с картой: 
. команда: СЕТ КЕЗРОМ$Е 
. ожидаемая дпина данных от карты: 16 
* длина данных, полученных от карты: 16 
. данные от карты: 77 ОЕ 82 02 38 00 94 08 28 01 03 01 30 01 02 00 
* код карты: 90 00 


* команда СЕТ РКОСЕ$5!МС ОРТЮМ$ завершена успешно 
* время выполнения команды: 203 мсек 
> в ответ на команду получены следующие данные: 770Е8202380094082801030130010200 
* интерпретация полученной ТЕ\-структуры:: 
* 77.14 Везропзе Меззаде Тетр!а{е РГогта{ 2 
* 82.2 АррИсайоп п{егсвапде Ргойе 
* 94.8 Аррйсайоп Ейе Госаюг 
* выполняется анализ данных, полученных в ответ на команду СЕТ РКОСЕЗ5!М6 ОРТОМ$ 
. команда предоставила следующие данные: 
. АррИсайоп |п{егспапде Ргойе: 3800 
* ООА зирройед 
‚ Сагапоег \Мепйсаноп зирропед 
. Тегтта! К!5К Мападетег! {0 Бе рейогтед 
* АррИсаНоп Рйе Госа‘ог: 2801030130010200 
* 5Р1 5, гесога$ 1 - 3, гесог4 1 пуомей п ОБА 
* ЭР 6, гесога$ 1 - 2 


Рис. 15. 'Грассировка обмена данными с картой. 


Персонализация 


Кнопка «Персонализация» предназначена для запуска процесса, с помощью 
которого можно проверить правильность персонализации платежного 
приложения по заданию на выпуск карты (файлу с данными для персонали- 
зации ЕМУ-приложения), сформированного подсистемой подготовки дан- 
ных персонализации из входных данных бэк-офиса банка-эмитента. 


Применение этой функции ограничено прежде всего тем, что для проверки 
правильности персонализации платежного приложения требуется ХМГ- 
файл, подготовленный подсистемой персонализации Ореп\/ау (\/ау4 благе 
Са Резо) для внешнего персо-бюро. С подсистемами персонализации 
других провайдеров персо-решений комплекс тестирования не работает. 


Кроме того, в полной мере проверка персонализации осуществляется только 
для платежного приложения РауУСОЕКМ№. Для других типов платежных прило- 
жений может быть выполнена только частичная проверка. 
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Информация 


При нажатии кнопки «Информация» на экране отображается окно с обоб- 
щенной информацией о последней проверенной карте. На рис. 16 показан 
фрагмент такой информации. Предоставляются следующие данные: 


" общая информация о карте и платежном приложении 

" результат выполнения команды СЕТ РКОСЕ$$ МС ОРТОЮМ5 
"= данные, считанные из файлов платежного приложения 

" ланные, считанные с помощью команды СЕТ ОАТА 


м некоторые дополнительные данные о платежном приложении. 


Общая информация о карте и проверенном платежном приложении. 
- АТК карты: 3В6Е00008031806680840С016ЕО183009000 
. карта была обработана в контактном режиме 
* АО платежного приложения (ОЕ Мате): Аб000000041010 
* данные из ЕС! платежного приложения: 
. АррИсайоп ГаБе!: 40617374657243617264 «Маз{егСага» 
. АррйсаНоп Рпощу пфсафог: 01 
‚ Гапдцаде Ргеегепсе: 7275656Е «гиеп» 
. од Епну: ОВОА 
‚ Трга Рапу ба: 06430000303000 
* Соипу Соде: 0643 
* /пюие еп ег аззюпеЧ Бу Маз{егСага: 0000 
. Оемсе Туре: «00» (Сага) 
* Ргорие{агу даа: 30 


Информация о платежном приложении, полученная при выполнении команды СЕТ РКОСЕ$ ИМС 
ОРТЮМ$. 
* АррИсайоп и{егсвапде Ргойе: 3900 
. ОБА зирропеа 
‚ СагаВо!Чег Мепйсаноп зирройед 
. Тепппа! РК Мападетег ю Бе рейогтед 
* СОА зирропеа 
* АррИсаноп ЕЙе Госа(ог: 10020201180101002001010028010200 
* ЭР! 2, гесог4 2, {$ гесога туомед т ОБРА 
* ЭР! 3, гесог4 1 
* ЗЕ! 4, гесог4 1 
’ ЭР! 5, гесог4$ 1-2 


Данные, считанные из файлов платежного приложения, 
* АррИсайоп РАМ: 5225980034347618 
* АррИсаНоп РАМ Зедиепсе Митьег: 00 
* АррИсайоп ЕНесНуе Ба: 01.10.2018 
* Аррисаноп Ехргайоп Ба(е: 30.11.2021 
* АррИсайоп Мегзюп Митьег: 0002 
* АррИсайоп Сштепсу Соде: 0643 
‚ Сагаподег Мате: 53494447524=5627564С41444940495220202020202020202020 'ЗООРОММ-АВМИВ ` 
* 15зцег Соитгу Соде (питепс); 0643 
. Аррисайоп Цзаде Сотго!: ЕЕ00 
„ уайа Гог Чотез#с сазВ {гапзасйопз 
„ уаН4 Гог ицегпайопа| сай {+гапзасНоп$ 
. уа!а ог Чотезйс 90045 
‚ уайа ог ицегайопа! 9004$ 
*. уаНа юг дотез#с зег/лсез 
. уаНа Юг и{егпавопа| зегисез 
. уаНа а! АТМ$ 
‚ уайа аЦептта!$ о\пег Пап АТМ$ 


Рис. 16. Информация о проверенной карте. 
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Обобщенная информация о последней проверенной карте можег быть 
просмотрена и сохранена в текущем каталоге программы в файле с именем 
Сака Ш.х.у, где х — дата, а у — время создания файла. 


Нужно обратить внимание на то, что обобщенная информация — это всего 
лишь выборка из тех данных, которые представлены в протоколе, итоги 
проверки платежного приложения. 


Если ещё не было обработано ни одно платежное приложение, то никакая 
информация не отображается. 


Исследование 


Кнопка «Исследование» инициирует процесс проверки заданного платежного 
приложения, находящегося на установленной карте. Прежде чем начать 
анализ платежного приложения, необходимо сделать следующее. 


1. Определить, каким образом будет осуществляться поиск платежного 
приложения на карте. Возможно, установить тип приложения. 


2. Установить среду проверки платежного приложения (задать параметры 
терминала, транзакции и эмуляции онлайновой обработки). 


3. Выбрать устройство чтения смарт-карт, в которое будет установлена карта 
с проверяемым приложением. 


4. Установить карту с проверяемым приложением в выбранное устройство. 


После нажатия кнопки «Исследование» проверка платежного приложения 
выполняется в автоматическом режиме и никакие действия от пользователя 
больше не требуются. 
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Приложения 


та глава содержит сведения справочного характера, которые могут 

помочь в понимании возможностей комплекса тестирования ЕСУ и 

избежать определенных ошибок при проверке платежных прило- 

жений. Ссылки на эти сведения присутствуют в других главах 
документа, но только в этой главе они представлены и объяснены в полном 
объеме. 


В данной главе приведено описание некоторых криптографических алгорит- 
мов, которые применяются картой, терминалом и эмитентом. Все эти 
алгоритмы подробно описаны в спецификациях ЕМУ. Здесь алгоритмы 
приведены, так как упоминались в тексте документа и являются общими для 
всех платежных приложений. Описание алгоритмов может использоваться 
только для справки и не должно применяться в других целях. При описании 
криптографических методов используются следующие соглашения. 


1. Для определения операции затифрования данных по алгоритму 'Гире 
ОЕ$ используется обозначение: ЗОЕЗЕСВ (Оэа, К) — зашифрование 
данных Оайа на ключе К в режиме ЕСВ. 


2. Для определения операций заттифрования и расшифрования данных с 
использованием алгоритма ВЗА используются следующие обозначения: 


® КЗАКРОВ (51оп, Кр) — восстановление данных из подписи Зюп на 
открытом ключе Кр (т. е. расшифрование данных на открытом ключе) 


® КЗАЗРКУ (аа, К5) — получение подписи данных Пайа на секретном 
ключе К$ (т. е. заилифрование данных на секретном ключе) 
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При вводе ключей платежного приложения (см. раздел «Определение 
ключей») существует три метода преобразования введенных ключи в ключи 
платежного приложения: 


" диверсификация (преобразование) ключей не выполняется 
" диверсификация ключей по опции А 
" диверсификация ключей по опции В 


В последних двух случаях считается, что в качестве ключей определены 
мастер-ключи эмитента, которые ДОЛЖНЫ быть диверсифицированы В КАюЮЧИ 
платежного приложения. 


В данном разделе описан алгоритм диверсификации мастер-ключа эмитента 
(МК) с использованием РАМ (Ргилагу Ассоипе Мате и РАМ Зедиепсе 
МипаБег. В результате такой диверсификации вычисляется ключ СМК, 
уникальный для платежного приложения. В соответствии с документом 
«ЕМУ. Ниеотиеа Сисой Саг4 ЗресмНсаноп$ Юг Рауплепе Зузепаз. Воок 2. 
Зесиу ап Кеу Мапаоетепе Уегзюп 4.2. ]апе 2008» эмитент можег 
использовать две опции для диверсификации мастер-ключа — опцию А и 
опцию В. 


Процесс диверсификации включает следующие шаги. 


1. Нсли РАМ содержит болыше 16-ти десятичных цифр и используется 
опция В диверсификации ключа, то выполняется переход к тату 2. Иначе, 
за десятичными цифрами РАМ располагаются цифры РАМ Зедиепйсе 
МатБег (если РАМ Зедиепсе МатБег не задан, то вместо него 
используется нулевой байт). Если результат Х содержит меньше 16-ти 
цифр, то он дополняется нулями слева, чтобы получить 8-ми байтное 
число У. Когла результат Х содержит по крайней мере 16 цифр, 8-ми 
байтное число У представляет собой 16 самых правых цифр результата Х. 
Выполняется переход к ттагу 3. 


2. Нсли РАМ содержит нечетное количество цифр, то он дополняется нулем 
слева. Затем за десятичными цифрами РАМ располагаются цифры РАМ 
Зедаейсе МипаБег (если РАМ Зедиепсе МипоБег не задан, то вместо него 
используется нулевой байт). Вычисляется хэш-функция полученного 
значения по алгоритму $НА-1, в результате чего будет получен 20-ти 
байтный результат Х. Затем выбираются первые 16 десягичных цифр из 
результата Х, чтобы получить 8-ми байтное число У. Если в числе У 
недостаточно десятичных цифр, шестнадцатеричные цифры Х 
преобразуются в десятичные путем вычитания 10. Например, если 
Х = '1230АВСр567842р4В179Е2САЗ45р26789А17В64ВВ', то значение 


> 


У = '1230567842417923' (первые 16 десятичных цифр результата Х). 
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Если Х = ПВЗСАВСРОбЕЗРАР4В1СРЕ2САРАЕРС78РА17ВбЕ ВВ', то зна- 
чение У = '1368412478176'. К этим десятичным цифрам затем добав- 
ляется результат преобразования шестнадцатеричных цифр '120' (полу- 
ченных из 'В', 'С'и'А' и число У = '1368412478176120". 


3. Вычисляется ключ СМК как результат выполнения слелующих операций: 


7 = ЗОЕЗЕСВ (У, МК) 

72 = ЗОЕЗЕСВ (У Ф 0хЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕ, 1МК) 

СМК — И | 72 
Таким образом, опция А диверсификации мастер-ключа является подмно- 
жеством опции В. Эмитент может использовать любую из опций, поскольку 


они абсолютно равнозначны. Разумеется, опция А более проста в реализации, 
а опция В — более продвинутая. 
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Для целого ряда действий с платежным приложением (выполнения офлай- 
новой аутентификации данных, предъявления зашифрованного РИ\-кода) 
терминал должен иметь публичный ключ карты. Чтобы получить публичный 
ключ карты из данных платежного приложения, терминал сначала должен 
восстановить публичный ключ эмитента из сертификата публичного ключа 
эмитента, подписанного на секретном ключе Сегийсаноп Аифошу (СА). 
Далее приведен алгоритм этого процесса. 


"Терминал выполняет следующие шаги ДЛЯ проверки сертификата 
публичног о ключа эмитента. 


1. Проверяет длину сертификата публичного ключа эмитента (она должна 
равняться длине модуля публичного ключа СА - Мса). 


2. Расшифровывает сертификат публичного ключа эмитента на публичном 
ключе СА (Рса) по формуле ВЗАВРОВ (Сегайсме, Рса). Расшифрованный 
сертификат должен иметь следующий вид. 


Смещение Длина Содержимое 


0 1 Заголовок сертификата (ОхбА). 
1 1 Идентификатор формата (0х02) 
2 4 Идентификатор эмитента (от 3-х до 8-ми самых 


левых цифр РАМ, дополненных при необходимости 
шестнадцатеричными цифрами Е справа) 


6 2 Дата истечения срока действия сертификата (п4 в 
виде ММУУ’) 
8 3 Серийный номер сертификата 


— 
— 
— 


Идентификатор хэш-алгоритма (0х01 — ЗНА1) 


— 
№ 
— 


Идентификатор алгоритма генерации сертификата 


(0х01 — ВАЗА) 
13 1 Длина модуля публичного ключа эмитента (№) 
14 1 Длина экспоненты публичного ключа эмитента (1 - 3) 
15 № а-—36 — Старшие (самые левые) байты модуля публичного 


ключа эмитента! 


№ а - 21 20 Значение хэш-функции для публичного ключа 
эмитента и связанной с ним информации 


№ са - 1 1 Идентификатор окончания сертификата (0хВС) 


1 Если № <= М№са - 36, то сертификат содержит весь модуль публичного ключа эмитента, 
дополненный справа байтами ОхВВ (количество байт дополнения равно Мса - № - 36). Иначе, 
сертификат содержит М№са - 36 старших байт модуля публичного ключа эмитента (остаток 
публичного ключа эмитента заносится в объект [3заег РаБ{с Кеу Вегтлашаею). 
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3. Проверяет идентификатор окончания сертификата (должен быль равен 
0хВС), заголовок сертификата (должен быть равен 0хбА) и 
идентификатор формата (должен быть равен Ох02). 


4. Получает значение хэш-функции по алгоритму ЗНА1 для конкатенации 
следующих элементов данных: 


"= идентификатор формага (0х02) 

" идентификатор эмитента 

" дата истечения срока действия сертификата 

"= серийный номер сертификата 

"= идентификатор хэт-алгоритма (0х01) 

" идентификатор алгоритма генерации сертификата (0х01) 
" длина модуля публичного ключа эмитента (№1) 

" длина экспоненты публичного ключа эмитента (1 — 3) 


" модуль публичного ключа эмитента (старшие байты модуля 
публичного ключа эмитента из сертификата, за которыми следуют 
младитие байты модуля из объекта данных [5заег Рас Кеу 
Веташаег, полученного от карты, или модуль публичного ключа 
эмитента из сертификата, дополненный справа байтами ОхВВ, 
если весь модуль поместился в сертификате) 


ыы экспонента публичног о ключа эмитента 


5. Сравнивает полученное значение хэш-функции со значением, 
определённым в сертификате. 


6. Проверяет, что идентификатор эмитента соответствует первым цифрам 
РАМ (при этом учитывается, что цифры идентификатор эмитента может 
содержать от 3-х до 8-ми самых левых цифр РАМ, дополненных при 
необходимости шестнадцатеричными цифрами Е справа). 


7. Проверяет, что срок действия сертификата не истек. 


8. Проверяет идентификатор алгоритма генерации сертификата (лолжен 
быть равен Ох01) 
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Если любая из перечисленных проверок не выполнена, то считается, что 
аутентификация карты провалилась. Иначе, сертификат публичного ключа 
верен и модуль публичного ключа эмитента извлекается из сертификата или 
получается путем конкатенации старших байтов модуля публичного ключа 
эмитента из сертификата и младих байтов модуля из объекга данных [55аег 


РаБ с Кеу Вепашдеи. 
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Для выполнения офлайновой аутентификации данных и предъявления 
зашифрованного РИМ\-кода терминал должен восстановить публичный ключ 
карты из сертификата публичного ключа карты, подписанного на секретном 
ключе эмитента. Для этого требуется публичный ключ эмитента. Процедура 
восстановления публичного ключа эмитента подробно описана в 
предыдущем разделе. После восстановления публичного ключа эмитента 
терминал восстанавливает публичный ключ карты, используя его сертификат. 
Терминал выполняет следующие шаги для проверки сертификата публич- 
ного ключа карты. 


1. Проверяет длину сертификата публичного ключа карты (она должна 
равняться длине модуля публичного ключа эмитента — №). 


2. Расшифровывает сертификат публичного ключа карты на публичном 
ключе эмитента (Р1) по формуле ВЗАВРОВ (Сегайсме, Р1. Расшифрован- 


ный сертификат должен иметь следующий вид. 


Смещение Длина Содержимое 


0 1 Заголовок сертификата (ОхбА). 

1 1 Идентификатор формата (0х04) 

2 10 АррИсавоп РАМ (дополненный справа 
шестнадцатеричными цифрами Е) 

12 2 Дата истечения срока действия сертификата (п4 в 
виде ММУУ’) 

14 3 Серийный номер сертификата 

17 1 Идентификатор хэш-алгоритма (0х01 — ЗНА1) 

18 1 Идентификатор алгоритма генерации сертификата 
(0х01 — ВАЗА) 

19 1 Длина модуля публичного ключа карты (Мс) 

20 1 Длина экспоненты публичного ключа карты (1 — 3) 

21 М- 42 Старшие (самые левые) байты модуля публичного 
ключа карты! 

М- 21 20 Значение хэш-функции для публичного ключа карты 


и связанной с ним информации 


М- 1 1 Идентификатор окончания сертификата (0хВС) 


1 Если №с <= №- 42, то сертификат содержит весь модуль публичного ключа карты, дополненный 
справа байтами ОхВВ (количество байт дополнения равно № - №с - 42). Иначе, сертификат 
содержит М! - 42 старших байт модуля публичного ключа карты (остаток публичного ключа карты 
заносится в объект 1СС Рис Кеу Веташ4ег) 
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3. Проверяет идентификатор окончания сертификата (должен быль равен 
0%хВС), заголовок сертификата (должен быть равен 0хбА) и 
идентификатор формата (должен быть равен Ох04). 


4. Получает значение хэш-функции по алгоритму ЗНА1 для конкатенации 
следующих элементов данных: 


" идентификатор формата (0х02) 

" АррИсаноп РАМ 

" дата истечения срока действия сертификата 

"= серийный номер сертификата 

"= идентификатор хэш-алгоритма (0х0Т) 

"= идентификатор алгоритма генерации сертификата (09х01) 
" длина модуля публичного ключа карты (с) 

" длина экспоненты публичного ключа карты (1 — 3) 


" модуль публичного ключа карты (старшие байты модуля публичного 
ключа карты из сертификата, за которыми следуют младитие байты 
модуля из объекта данных 1СС РаБ с Кеу Кеташаег, полученного от 
карты, или модуль публичного ключа карты из сертификата, 
дополненный справа байтами ОхВВ, если весь модуль поместился в 
сертификате) 


"= экспонента публичного ключа карты 


"= статические данные, которые должны быть аутентифицированы 
(могут отсутствовать) 


Статические данные, которые должны быть аутентифицированы, 
определяются элементами списка АЕГ. (Аррйсавоп Ре Госахог) в том 
порядке, в котором они появляются в списке АЕГ и считываются 
терминалом. Данные, включаемые в процесс аутентификации, зависят от 
ЗБок Ее 1Чепайег (ЗЕТ) файла, из которого считываются записи. 


" для файлов с ЗН в диапазоне от 1 до 10 тэг записи (70) и длина записи 
исключаются из процесса аутентификации. Все другие элементы 
данных из записи включаются. 


" для файлов с ЗЕ в диапазоне от 11 до 30 тэг записи (70) и длина 
записи, а также другие элементы данных включаются в процесс 
аутентификации. 
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После того как все элементы, определяемые АЕГ, включены в состав 
статической информации, которая должна быть аутентифицирована, 
обрабатывается 5а4с Ома АпфепйсаЧоп 'Тао [156 если он определен в 
данных, считанных терминалом по команде ВЕАР КЕСОКО. $аас Рав 
Аифепасавоп 'Гао 119% если он задан, может содержать только тэг для 
АррЁсавоп Циегсрапое Рго@е (АТР). 'Гаким образом, если элемент данных 
авс аа Аифепйсайоп 'Гас [15 определен, то значение АГ? заносится в 
конец статических данных, которые должны быть аутентифицированы 
(тэг и длина АГ? не включаются). 


5. Сравнивает полученное значение хэш-функции со значением, 
определённым в сертификате. 


6. Проверяет, что АррИсавоп РАМ, определенный в сертификате, 
соответствует АррИсавоп РАМ, полученном от платежного приложения. 


7. Проверяет, что срок действия сертификата не истек. 


8. Проверяет идентификатор алгоритма генерации сертификата (лолжен 
быть равен 0х01) 


Если любая из перечисленных проверок не выполнена, то считается, что 
офлайновая аутентификация данных провалилась. Иначе, сертификат 
публичного ключа верен и модуль публичного ключа карты извлекается из 
сертификата или получается путем конкатенации старших байтов модуля 
публичного ключа карты из сертификата и младших байтов модуля из 
объекта данных 1СС Рис Кеу Кетапает. 
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Метод офлайновой аутентификации данных, который называется СОА 
(СотЫтеа ава Аяфепйсаноп) сейчас наиболее распространен для карточ- 
ных продуктов. Это самый сложный из методов офлайновой аутентифи- 
кации, в связи с чем анализ платежного приложения, использующего метод 
СОА, может вызвать затруднения. В связи с этим приводится описание 
операций, которые должны выполнить карта и терминал, чтобы обеспечить 
офлайновую аутентификацию данных по методу СОА. 


Подпись СОА (сертификат, предоставляемый в объекте Зюпе@ Гупапис 
АррИсаноп Гала), генерируется картой по определенному алгоритму. В 
процессе генерации сертификата выполняются следующие действия. 


Сначала формируются данные сертификата З1юпе4 Оупапус АррИсаноп Рая. 
Данные представляются в виде поля фиксированной длины, размер которого 
равен длине ключа карты (с). Поле имеет слелующтий формат. 


Смещение Длина Содержимое 
0 1 Заголовок сертификата (0хбА). 
1 1 Идентификатор формата (0х05) 
2 1 Идентификатор хэш-алгоритма (0х01 — ЗНА1) 
3 1 Длина динамических данных в байтах (38). В табли- 
це динамические данные выделены цветом. 
4 1 Длина |СС упатс Митбег (8) 
5 8 [СС Бупатю Митбег 
13 1 Сгурюдгат шюЮптайоп Ба (СО) 
14 8 Криптограмма (ТС или АВОС) 
22 20 Тгапзасноп Оаа Назй Соде 
42 № -63 — Байты со значением 0хВВ 
№ -21 20 Бупатс Аррйсайоп Ваа Назп 
№ - 1 1 Идентификатор окончания сертификата (0хВС) 


Необходимо дать несколько пояснений к элементам данным, используемым 
платежным приложением АЛЯ генерации сертификата. 


1. 1СС Оупапие МатаБег — это кринтографическая функция от значения 
АТС, которая определяется разработчиком платежного приложения. 
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2. Тгапзасвоп Рав НазЬ Соае — значение хэш-функции по алгоритму $ЗНА1 
для конкатенации следующих элементов данных: 
" значения элементов, указанных в РООГл 
"= значения элементов, указанных в СООТ 


"= значения элементов, указанных в СООГ2 (только для второй команды 
СЕМЕКАТЕ АС — для первой команды СЕМЕКАТЕ АС это поле 
опущено) 


"= объекта Сгурюстат шЮптланоп Дала с тэгом 9Е27 и длиной 1, объекта 
АТС с тэгом 9Е36 и длиной 2, объекта [5заег АррИсаноп Рала с тэгом 
9Е10 и длиной 322 


3. Пупапис АррЁсаноп Ома НазЬ — значение хэш-функции по алгоритму 
ЗНА1 для конкатенации следующих элементов данных: 


" идентификатор формага (0х05) 

" идентификатор хэт-алгоритма (0х01) 

" длина динамических данных в байтах (38) 

"= линамические данные 

"= байты со значением ОхВВ (длиной №с - 63) 


" 4-х байтгное случайное число терминала, переданное карте в 


списке СООГЛ или СООГ2 


Подготовленные данные подписываются (заифровываются) на секретном 
ключе карты (СС Риуме Кеу — Усс) по формуле ВЗА$РКУ (Ра, Усс) в 
результате чего формируется сертификат 51юпе4 Оупапис Аррйсаноп Ра. 


Терминал, получив от карты сертификат Зюпе@ Оупапис Аррсаноп ав, 
выполняет следующие шаги для проверки предоставленного сертификата 
(аутентификации карты). 


1. Проверяет длину предоставленного сертификата (она должна равняться 
длине модуля [СС РаБ{с Кеу — №6). 


2. Расшифровывает сертификат на публичном ключе карты (СС Рис Кеу 
— Р1сс) по формуле ВЗАВРОВ (Сегайсме, Р1сс). 


и Если список РООТ, не используется, то поле должно быть опущено. 


2 Это объекты, которые возвращены в ответ на команду СЕМЕКАТЕ АС в том порядке, в котором 
они представлены в ответе (за исключением объекта Зюпе4 упатс АррЁсаноп Пава). 
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3. Проверяет идентификатор окончания сертификата (должен быль равен 
0хВО), заголовок сертификата (должен быть равен ОхбА) и идентифика- 
тор формата (должен быть равен 0х05). 


4. Сравнивает Сгурюстат шЮнтаноп Оаа из сертификата со значением 
Стурюотапл шоппаноп ака, возврашенным командой СЕМЕКАТЕ АС. 


5. Вычисляет Оупапис АррИсавоп Оэа НазБ по тому же алгоритму, что и 
карта, и сравнивает полученное значение со значением, определённым в 
сертификате. 


6. Вычисляет Тгапзасной ава НазЬ Соде по тому же алгоритму, что и карта, 
и сравнивает полученное значение со значением, определённым в 
сертификате. 


Если любая из перечисленных проверок не выполнена, то считается, что 
аутентификация карты провалилась. 
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В этом разделе приведен пример протокола исследования платежного прило- 
жения, удовлетворяющего спецификациям МазегСат4. Рекомендуется обра- 
тить внимание на следующие особенности исследования: 


ы транзакция выполнена в контактном режиме 


" успешно выполнена офлайновая аутентификация данных карты с 
использованием метола СОА 


" выполнен метод верификации владельца карты «Предъявление РПМ- 
кода для передачи его эмитенту», так как предъявление РИ\-кода карте 
провалилось из-за неправильного значения РП\-кола 


" выданы команды СЕТ ЛРАТА для получения информации об 
объектах платежного приложения 


" первая команда СЕМЕКАТЕ АС вернула криптограмму АКОС и была 


выполнена эмуляция онлайновой обработки 


" выдана вторая команда СЕМЕКАТЕ АС для завершения транзакции. 
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Инициировано исследование установленной карты с платёжным приложением. В процессе анализа карты будут использо- 
ваться следующие параметры: 
® тип терминала: 22 
® АЦепаеа, ОНте м ИИ оп!пе сараб Му 
® ОрегаЧопа! соп{го! ргомаеа Бу МегспапЕ 
® возможности терминала: 
® Сага Ча{а при{ сара Ку: Мавпенс $ пре, [С миН сотас$ 
® С\/М сарабИйу: Р!айщехе РИМ Гог [СС мейЯсайоп, Епарпегед РИМ Гог оп!те мейЯсаНоп, З!впафиге (рарег), Епсррегеа РИМ Гог 
о те уегЯсаНоп, М№о СУМ а!омеа 
® бесигКу сара ИИу: $ОА, ОБА, СОА 
® расширенные возможности терминала: 
® ТгапзасНоп {уре сара Ну: боод$, Зегп/сез, паиху, Адатит га ме 
® ТгапзасНоп Чата при{ сара Ку: Митенс Кеуз, ЕипсНоп Кеуз 
® ТгапзасНоп Чака оиёри{ сара Ку: Рип (аЦепдап®), О!5р!ау (аЦепЧап) 
® Соде {аЫез: 5 (1ап/Сугс: кириллица, включающая символы славянских языков} 
® страна, в которой расположен терминал: Российская Федерация 
® параметры процедуры управления рисками терминала (Теттта! В15К Мапаветеп{: 
® максимальное значение суммы платежа в офлайновом режиме (Тегтта! Ноог Итй): 1000.00 
® целевой процент, используемый в процедуре случайного выбора транзакции для онлайновой обработки: 20 
® пороговое значение суммы платежа для пристрастного выбора, используемое в процедуре случайного выбора 
транзакции для онлайновой обработки: 500.00 
® максимальный целевой процент пристрастного выбора, используемый в процедуре случайного выбора транзакции 
для онлайновой обработки: 60 
® тип транзакции: 00 (покупка товаров или услуг) 
® сумма платежной операции: 20.00 
® другая сумма (сумма сазПБаск): 0.00 
® валюта платежной операции: русский рубль 
® дата транзакции: 12.02.2019 
® время транзакции: 20:07:37 
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При проверке платежной карты выполняются следующие обязательные шаги и опциональные действия, запланированные 
пользователем. 
1. Первоначальный анализ установленной карты. 
® АТК карты: ЗВ 6Е 00 00 80 31 80 66 ВО 84 0С 01 6Е 01 83 00 90 00 
® предполагается контактный режим 
® протокол: ТО 
2. Установка проверяемого платежного приложения в качестве текущего приложения на карте (операция, с которой начи- 
нается любая платежная транзакция). 
® осуществляется холодный сброс карты, чтобы исключить побочные эффекты предыдущих действий 
® установка текущего приложения с помощью команды $ЕТЕСТ 
® вответ на команду получены следующие данные: 
6Е 33 84 07 АО 00 00 00 04 10 10 А5 28 500А 40 
61 73 74 65 72 43 61 72 64 5Е20 04 72 75 65 6Е 
87 01 01 ВЕОСОЕРУЭЕ Ар 02 ОВ ОА 9Е 6Е 07 06 43 
00 00 30 30 00 
® интерпретация полученной ТИ\-структуры: 
® 6Е.51 Е Тетр!а*е 
® 84.7 Оефса{еа Ее Мате 
® Д5.40 ЕС! РгорйЕ{агу Тетр!а{е 
® 50.10 АррйсаНЧоп ГаБе! 
® 520.4 [апвиаве Ргеегепсе 
® 87.1 АррИсаНоп РпогЙу шсафог 
® ВЕОС.15 ЕС! 155иег О15сгеНопагу Вафа 
® ЭЕ4О.2 1о8 Епгу 
® ЭЕбЕ.7 Т№га Рацу Бака 
® выполняется анализ данных, полученных в ответ на команду 5ЕТЕСТ (анализ ЕС! платежного приложения) 
® в Е платежного приложения найдены следующие объекты, которые могут использоваться при обработке транз- 
акции: 
® ОеЧ'са{е4 Ее Мате: АО000000041010 
® АррИсаЧоп [аБе!: 40617374657243617264 'МачегСага' 
® АррИсаНоп РИогКу шсафог: 01 
® [апвиаве Рге{егепсе: 7275656Е 'гиеп' 
® [05 Емгу: ОВОА 
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® Триа Рацу Бака: 06430000303000 
® Соип{ту Сосе: 0643 
® Цпаце епЕег аз$епеа Бу Ма$егСага: 0000 
® Оемсе Туре: «ОО» (Сага) 
® РгорйЕагу Чака: 30 
® платежное приложение будет обрабатываться в соответствии со спецификациями Ма$егСага 
3. Получение значений объектов платежного приложения, определенных в общих спецификациях ЕМ\ и детальных специ- 
фикациях платежного приложения (с использованием команды СЕТ ВАТА). 
® выдача команды СЕТ БАТА для получения значения объекта АррйсаЧоп ТгапзасНоп Соитег (АТС) 
® значение объекта платежного приложения не получено (объект отсутствует в платежном приложении) 
® выдача команды СЕТ ВАТА для получения значения объекта 1а5{ Оп!те АТС Вейег 
® значение объекта платежного приложения не получено (объект отсутствует в платежном приложении) 
® выдача команды СЕТ ОАТА для получения значения объекта РИМ Тгу Соищег 
® время выполнения команды: 16 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ВАТА для получения значения объекта 105 Еопта{ 
® время выполнения команды: 46 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ БАТА для получения значения объекта Сага 155иег АсНоп Соде — Весте 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ БВАТА для получения значения объекта Сага |55иег АсНоп Соде — БеаиК 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ВАТА для получения значения объекта Сага 155иег АсНоп Соде — Оп!пе 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ БВАТА для получения значения объекта Соитег$ 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ВАТА для получения значения объекта СОО!1 Ве!а{ед Ба{а 1еп{и 
® время выполнения команды: 32 мсек 
® значение объекта сохраняется для дальнейшей обработки 
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® выдача команды СЕТ ВАТА для получения значения объекта Сага В!5К Мапаветепе Соитхту Соде 
® время выполнения команды: 32 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ВАТА для получения значения объекта Сага В!5К Мапазетепе Сиггепсу Соде 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ВАТА для получения значения объекта 1о\мег Ситиа ме Оте ТгапзасНоп Атоипе 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ БАТА для получения значения объекта Уррег Ситиа ме О те ТгапзасНоп Атоип* 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ОАТА для получения значения объекта Сага |55иег Асйоп Соае (СотасЦез$) — Беаи! 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ВАТА для получения значения объекта Сага |5зиег АсНоп Соае (Сопкас{ез$) — Опте 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ВАТА для получения значения объекта Сага |5зиег АсНоп Соде (СопкасЦез$) — Вефте 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ВАТА для получения значения объекта Сиггепсу Сопуег$!оп Тае 
® время выполнения команды: 62 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ВАТА для получения значения объекта АЧ4юопа! СНеск ТаЫе 
® время выполнения команды: 47 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ БАТА для получения значения объекта АррИсайоп Соп\го! 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ БВАТА для получения значения объекта БеЁаи АВРС Везропзе Соде 
® время выполнения команды: 32 мсек 
® значение объекта сохраняется для дальнейшей обработки 
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® выдача команды СЕТ ВАТА для получения значения объекта АррйсаНоп Сопёго! (СопасЧез$) 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ВАТА для получения значения объекта 1о\иег Сопзеси ме ОНте Итй 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ БАТА для получения значения объекта Уррег Сопзесий\е ОНте Итй 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ ВАТА для получения значения объекта ОНте Ва!апсе 
® значение объекта платежного приложения не получено (объект недоступен в данном контексте) 
® выдача команды СЕТ ВАТА для получения значения объекта Ва{а Весо\мегу БОЕ 
® значение объекта платежного приложения не получено (объект отсутствует в платежном приложении) 
® выдача команды СЕТ ОАТА для получения значения объекта Аррйсайоп Ше Сусе Ба{а 
® время выполнения команды: 79 мсек 
® значение объекта сохраняется для дальнейшей обработки 
® выдача команды СЕТ БАТА для получения значения объекта 5$есигКу Итй$ З{ати$ 
® время выполнения команды: 31 мсек 
® значение объекта сохраняется для дальнейшей обработки 
4. Проверка и интерпретация значений объектов платежного приложения, считанных с помощью команды СЕТ ВАТА. 
® анализ данных, полученных от платежного приложения 
® РМ Тгу Соикег: 3 (03) 
® [05 Гоптае: 9Е27019Е02065Е2А029А039Е36029Е5206 
® 927.1 Сгуртовгат |погтаНоп Бака (СО) 
® 902.6 АточциЕ, АшНоп?е4 (питейс) 
® 5Е2А.2 ТгапзасНоп Сигепсу Со4де 
® ЭА.3 Тгапзасйоп Ва{е 
® 9Е36.2 АррИсаНоп ТгапзасНоп Соит{ег (АТС) 
® 952.6 Сага МетЯсаНоп Вези!$ (С\УВ) 
® Сага |55иег АсНоп Соде — Бес!те: 000000 
® Сага |55цег Асйоп Соде — Бефаик: 195000 
® Опе РИМ уейЯсайоп Тайед 
® Ри {гу К ехсеедеад 
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® Тегллта! еггопеои$у соп$4ег$ оте РИМ ОК 
® ОИррег соп5еси\ме оТте Пт ехсеедед 
® Иррегсити!а ме о те Шт й ехсеедеа 
® Сага |55иег АсНоп Соде — Оп!те: З9ЕВО0 
® Опе РИМ мегЯсайоп по реМогтед 
® Опе РИМ уейЯсайоп Тайед 
® Ри {гу т ехсеедеад 
® Тегллта! еггопеои$у соп$4ег$ оте РИМ ОК 
® [о\/ег сопсесийуе о те т ехсеедед 
® Иррег сопзесий\ме оТте Пт ехсеедед 
® [о\м/егситиаН\е о те т ехсеедеа 
® Иррегсити!а ме о те Шт й ехсеедеа 
® 60 оппе оп пех {гапасйоп \ма$ е{ 
® 5С Пре гесемея 
® сре Гайед 
® Соищег5: 00380000000000000000 
® АТС: 0038 
® С|оБа| МАС т $спрЕ Соитег: 0 
® Ва Сгурозгат Соштег: 0 
® СОО!1 Кеа{е4 Бака 1епя11: 43 (28) 
® Сага В15К Мапаветеп{ Соитту Соде: 0643 
® Сага В15К Мапаветеп{ Сиггепсу Соде: 0643 
® [омег Ситиа ме О те ТгапзасНоп Атоип:: 1500.00 
® Иррег Сити!а \е О те Тгапзасйоп АтоипЕ: 1600.00 
® Сага |55цег АсНоп Соде (СотасИез$) — БегаиК: 005800 
® Иррег сопзеси\е о НЧте т ехсеедед 
® ОИррегситиа \е о те т ехсеедед 
® 60 опте оп пех {гапзасйоп \ма$ зе{ 
® Сага |55цег Асйоп Соде (Сот{ас{ез$) — Оп!пе: 00Е800 
® [о\м/ег сопзесий\е о те Итй ехсеедед 
® Иррег сопзеси\е о Нте т ехсеедед 
® [ом/егсити!ай\е о те т К ехсеедея 
® ОИррегситиа \е о те т ехсеедед 
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® 60 оппе оп пех {гапзасйоп \ма$ е{ 
® Сага |55цег АсНоп Соде (СощасНез$) — Вес!те: 080000 
® Ри {ту тпЁ ехсеедед 
® Сиггепсу Сопуег$оп ТаЫе: 06430000000643000000064300000006430000000643000000 
® Сиггепсу соае: 0643 
® Соп\уегзоп ас{ог: по{ Чейпед 
® Сиггепсу соае: 0643 
® Соп\уегзоп Гас{ог: по{ Чейпед 
® Сиггепсу соае: 0643 
® Сопуегзоп Гас{ог: по{ Чейпед 
® Сиггепсу соае: 0643 
® Сопуегзоп гас{ог: по{ Чейпед 
® Сиггепсу соае: 0643 
® Сопуегзоп Тас{ог: по{ дейпед 
® АЧаопа! СВеск ТаЫе: ООООООРРЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕ 
® ТПеге [5 а опта! еггог т {Пе Ада юпа! СПеск ТаЫе: 
® АррИсаНоп Сопёго!: 8С00 
® МавпеНс 5{пре эгаде 15зиег асИ\атед (аПо\мз {Не саг {о ассер{ {гапзасйоп$ мПеп 1[5зиег АиНепйсаНоп Чака 1$ пот 
ргезеп{) 
® Опе епсгур*ед РИМ уетЯсаНоп зирроцед 
® [СС Кеу Гого те епсгур*еа РИМ уейЯсайоп 
® Опе р!айщехЕ РИМ уеЯсайоп зирропея 
® Ма$егСага ргорйЕагу 5ез$1оп Кеу ЧейуаНоп 
® Оеаи{ АВРС Везропзе Сочде: 0010 
® РИМ Тгу Соищег: 0 
® Аррго\уе оппе {гапзасНоп 
® Бо по{ ирда{е РИМ Тгу Соищег 
® Везе{ во опте оп пех {гапзасйоп 
® Ордае соитщегз: 4о по{ ир4а{е о те соитег$ 
® АррИсаНоп Соп{го! (СопасИез5): 000080 
® Мавпейс {пре эгаде 155иег по{ асИ\уа{еа 
® Ма$егСага ргорйЕагу 5ез$!оп Кеу ЧейуаНоп 
® (зе 5(аНс С\/СЗ (РауРаз$} 
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® [о\мег Сопзесий\е О те Ити: 05 
® Иррег Соп5еси ме Оте Итий: 06 
® АррИсаНоп Ме Сусе Бака: 
03 10 19 12 0009 00 00 А1 А2 АЗ А4 А5 Аб А7 АЗ 
АЭ АА АВ АСАО АЕАЕВО ВЛ В2 ВЗ В4 С1 С2 СЗ С4 
С5 Сб С7 С8 С9 СА СВ СС СО СЕ СЕ 00 01 02 03 04 
® \/егз1оп: М/СНр 5е!есЕ 4 
® Туре Арргома! 1: 10191200090000 
® АррИсаНоп 1|5зиег 0: АЛА2АЗА4...В1В2ВЗВ4. 
® АррИсаНоп Соае О: С1С2С3С4...01020304 
® еси йу ИтИ5 Зафиз: 00 
5. Выполнение команды СЕТ РКОСЕ$$!М6 ОРТШОМ$ для инициирования транзакции и получения информации, необходимой 
для выполнения транзакции. 
® для инициирования транзакции никакие данные не нужны, поскольку не определен РОО, и в качестве входных дан- 
ных команды предоставляется объект Соттапа Тетр!а{е (тег 83) с нулевой длиной 
® платежному приложению передается команда СЕТ РКОСЕ$УМ 6 ОРТОМ$ 
® команда СЕТ РКОСЕЗ$$!М С ОРТШОМ5$ завершена успешно 
® время выполнения команды: 78 мсек 
® в ответ на команду получены следующие данные: 771682023900941010020201180101002001010028010200 
® интерпретация полученной ТИ\-структуры: 
® 77.22 Кезроп5е Меззаве Тетр!а{е Еопта*{ 2 
® 82.2 АррИсайоп и\{егсрапёе РгоЙе 
® 94.16 АррИсаНоп Ее [оса{ог 
® выполняется анализ данных, полученных в ответ на команду СЕТ РКОСЕЗ$!М 6 ОРТОМ5 
® команда предоставила следующие данные: 
® АррИсаНоп п\{егсрапее Ргойе: 3900 
® ОБА 5ирропеа 
® Саг4по!аег /ейЯсаНоп зирроцеа 
® Теглта! К!5К МапаветепЕ {о Бе рефогтед 
® СОА 5ирропеа 
® АррИсаЧоп Ее 1оса{ог: 10020201180101002001010028010200 
® $Е| 2, гесога 2, {5 гесога шмо№е т ОБА 
® ЗН 3, гесога 1 
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® ЗН Д, гесога 1 
® ЭН 5, гесог$ 1 -2 
6. Чтение данных из записей файлов платежного приложения. 
® выдается команда КЕАО КЕСОВР для чтения записи 2 из файла с идентификатором 2 
® время выполнения команды: 172 мсек 
® вответ на команду получены следующие данные: 
70 81 8С5А 08 52 25 98 00 34 34 76 18 5Е 24 03 
21 113057 25 03 18 1001 5-28 02 06 43 5Е 34 
01 008С21 9Е 02 06 ЭР 03 06 ЭЕ ЛА 02 95 05 5Е 
2А 02 9ЭА 03 9С 01 9Е 37 04 9Е 35 01 9Е 45 02 9Е 
4С 08 9Е 34 03 80 0С 91 ОА 8А 02 95 05 9Е 37 04 
ЭЕ4С 08 8Е 14 00 00 00 00 00 00 00 00 42 01 44 
03 41 03 42 03 1Е 03 1Е 03 9ЭЕ 07 02 ЕЕ 00 ЭЕ ОБ 
05 ВС50 ВС 88 00 9Е ОЕ 05 00 00 00 00 00 ЭЕ ОЕ 
05 ВС 70 ВС 98 00 9Е 42 02 06 43 ЭЕДА 01 82 
® интерпретация полученной ТИ\-структуры: 
® 70.140 КЕАБ КЕСОВО Тетр!а{е 
® 5А.8 АррИсайоп РАМ 
® 5224.3 АррИсаНоп ЕхргаНоп Байе 
® 5225.3 АррИсаНоп ЕНесйуе Ба{е 
® 5Е28.2 155иег Соипигу Соде (питейс) 
® 5Е34.1 АррйсаНоп РАМ 5едиепсе МитБег 
® 8С.33 Сага В15К Мапаветепе БОЕ 1 (СОО11) 
® 80.12 Сага В15К Мапаветепе БОЕ 2 (СОО12) 
® 8Е.20 С\/М $ 
® 9707.2 АррИсаНоп Цзаве Сопго!| 
® 9700.5 1АС-БеРаи! 
® ЭГОЕ.5 1АС-Беп!а! 
® ЭЕОЕ.5 1АС-Опте 
® 9.42.2 АррИсаНоп Сиггепсу Соде 
® ЭЕДА.1 {айс Байа Ац{еписаНоп Тав М5 
® объекты из считанной записи сохраняются для дальнейшей обработки (все элементарные объекты данных из записи 
будут использоваться для офлайновой аутентификации данных) 
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® выдается команда КЕАВ КЕСОВО для чтения записи 1 из файла с идентификатором 3 
® время выполнения команды: 266 мсек 
® вответ на команду получены следующие данные: 
70 81 ЕО 8Е 01 05 90 81 ВО 94 ЕР 79 ВО 06 7В 12 
46 39 00 89 1Е ВЗ СЕЕА АС5АА1 44 9Е 45 09 ЕВ 
ЗЕ С5 Е1 ВО 99 АС ЕР 5В 01 40 С8 02 60 55 С4 55 
6А 97 01 62 08 АС 61 29 А5 Е8 1Е0Е 11 86 2Е 02 
05 Е1 АО 18 ВВ 98 12 39 8820 22 35 58 80 68 4А 
59 25 18 01 ВА 74 ОВ С0 С9 59 4А ЕР 35 02 Еб 41 
ЭЕЕ1 С2 80 ВЕ 69 63 61 16 В8 6Е ВС В8 64 4А Е4 
5В 83 69 37 49 9В 6С 74 52 ЭЕ ЕЕРСОС 08 09 8А 
76 55 СЕ 63 СЗ ЕЗ 91 Е 50 Е9 ВБ Е1 31 Е1 С5 7А 
48 Е7 ВА ЕБ 04 С5 3048 99 1Е 16 6С СА ЕБ 7С 6Е 
ЕА 91 СА 65 6Е 20 20 ЕА С7 14 60 [4 ЕВ ОА 48 1В 
42 46 30 ЕЗ 92 ЗЕ 61 70 47 92 24 С9 ВС 26 10 83 
101 Аб А7 ОВ А? ЕЭ Еб 33 40 1А 54 0Е 40 57 ВБ 
56 49 Е8 ЕЗ 15 8Е2С 03 ОА 22 3С 45 В6 Е7 ЕВ 9Е 
32 01 03 
® интерпретация полученной ТИ\-структуры: 
® 70.224 ВЕАБ КЕСОВО Тетр!а{е 
® 8Е.1 СА Ри Кеу паех 
® 90.176 |55иег Риб[с Кеу Сегсае 
® 92.36 [55иег РиБс Кеу Кетатаег 
® 9Е32.1 155иег Рис Кеу Ехропеп+ 
® объекты из считанной записи сохраняются для дальнейшей обработки 
® выдается команда КЕАО КЕСОВР для чтения записи 1 из файла с идентификатором 4 
® время выполнения команды: 31 мсек 
® в ответ на команду получены следующие данные: 70049Е470103 
® интерпретация полученной ТИ\-структуры: 
® 70.4 КЕАО ВЕСОВО Тетр/ае 
® 9.47.1 [СС Рис Кеу ЕхропепЕ 
® объекты из считанной записи сохраняются для дальнейшей обработки 
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® выдается команда КЕАО ВКЕСОВО для чтения записи 1 из файла с идентификатором 5 
® время выполнения команды: 93 мсек 
® вответ на команду получены следующие данные: 
70 47 ЭЕЛЕОР 31 30 31 38 36 30 30 30 30 30 32 
30 38 57 13 52 25 98 00 34 34 76 18 02 11 12 01 
10 18 60 00 00 20 8Е 5Е 20 1А 53 49 44 4Е 52 4Е 
562556 4С 41 44 49 40 49 52 20 202020 20 20 
20 2020 20 9Р 08 02 00 02 
® интерпретация полученной ТИ\/-структуры: 
® 70.71 КЕАО ВЕСОКО Тетр/а*е 
® ЭЕ1Е.13 Тгаск 1 О15сгеЧопагу Вайа 
® 57.19 Тгаск 2 Едима!ете Бава 
® 5Е20.26 Саг4По!аег Мате 
® 9708.2 АррйсаНоп Мегзюоп Митбег 
® объекты из считанной записи сохраняются для дальнейшей обработки 
® выдается команда КЕАБ КЕСОВР для чтения записи 2 из файла с идентификатором 5 
® время выполнения команды: 219 мсек 
® вответ на команду получены следующие данные: 
70 81 ВА 9Р 46 81 ВО 91 70 25 34 98 48 68 ЕЗ 40 
43 52 09 74 8С 5Е 91 2С В1 80 18 Е? 74 83 53 20 
87 6ЕВб 75 00 20 С2 71 93 5А 71 08 Е5 АЗ АБ 10 
63 0701 69 ВЕЕЕ 83 20 25 39 07 90 [8 99 Е? В7 
69 05 Е4 68 39 16 С6 10 6ЕЗА АВ Еб 56 04 СЕ 65 
50 7А С6 В2 09 4А 55 30 59 44 66 ВР В8 ЕА 53 80 
06 80 6Е АЭ Е3 81 91 В1 06 ЭВ 73 10 ЕЗ ЕБ 95 62 
19 8С 39 60 59 50 73 72 А4 ЕО 06 52 07 ВЕВ1 66 
5В ЕС 64 60 ЕЕ СВ 05 АЕ ЗО В8 99 ВО 70 7А Еб АА 
70 08 Еб 9Е АЭ 07 СО 1С 08 ЕВ ЗЕ ВО 8ЕЕ? 64 31 
ОА 10 58 91 97 0С 60 24 С0 ЗЕ ЛА 59 В4 10 Е8 ЗБ 
7Е 69 08 0С 01 6В 03 9Е 49 03 9ЭЕ 37 04 
® интерпретация полученной ТИ\-структуры: 
® 70.186 КЕАБ КЕСОВО Тетр!а{е 
® 9Е46.176 [СС Рис Кеу СегЯсае 
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® 9Е49.3 Вупаптс Ваёа АщйепйсаНоп ОО! (001) 
® объекты из считанной записи сохраняются для дальнейшей обработки 
7. Анализ и интерпретация данных, считанных из файлов платежного приложения, в соответствии с общими спецификаци- 
ями ЕМУ. 
® известные объекты, сохраненные в базе данных терминала 
® АррИсаЧоп РАМ: 5225980034347618 
® АррИсаНЧоп РАМ 5$едиепсе Митрег: 00 
® АррИсаНоп ЕНесН\е Бате: 01.10.2018 
® АррИсаНоп Ехр!аНоп Ба%е: 30.11.2021 
® АррИсаЧоп \ег$юоп Митрег: 0002 
® АррИсаЧоп Сиггепсу Соде: 0643 
® СагЧПо!4ег Мате: 5349444Е524Е562Е564С41444940495220202020202020202020 'УООВОМ/МЕАРИМИВ ' 
® |5зиег Соитту Соде (питейс): 0643 
® АррИсаНоп Цзаве Соп\го!: ЕЕОО 
® уа!! Гог Чотес са$И {гапзасНоп$ 
® уа!! Гог и{егтай опа! саЁ 1гапзасйоп$ 
® уа! Гог дотез$с #0045 
® уа!4 Гог и{етаНопа| 5004$ 
® уа! Гог аоте$Нс егЛсе$ 
® уа!! Гог и{егпайопа| зег\/се$ 
® а! аЁ АТМ5 
® уа!4 а{ {егтта|5 о{Нег {Нап АТМ$ 
® С\/М Н5Е: 000000000000000042014403410342031ЕОЗ1Е03 
® АтОЧПЕХ =0 
® АточпЕ У =0 
® 4201 (епсрВегеа РИМ метНе4 оп!пе, # ипаКепдеч сазП, арр зиссее Чтв гше) 
® 4403 (епсрВегеа РИМ мейЯсайоп ре огтеч Бу СС, № {егтта! зирро$ С\/М, арру зиссее4 тя ге) 
® 4103 (рай\ехЕ РИМ мейЯсайоп ре огтеа Бу СС, Ш тегтта! зиррой5 СУМ, аррУ зиссее4тв гие) 
® 4203 (епс!рВегеа РИМ уетЯе4 опИпе, #{егтта! зиррог$ СУМ, арр\! зиссее4 те гие) 
® 1ЕОЗ ($1епа{иге, И щегтта! зирроп$ С\М, Рай саг4По!4ег уеййсайоп) 
® 1Е03 (по С\/М гедигеа, Н{егттта! зиррой$ СУМ, {ай саг4по!дег мейЯсаЧоп) 
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® Сага В15К Мапаветеп{ ООЕ 1 (СОО!1): 
ЭЕ02 06 9Е 03 06 ЭЕ 1А 02 95 05 5Е2А 02 9А 03 
9С 01 9Е 37 04 9Е 35 01 9Е 45 02 9Е 4С 08 9Е 34 
03 
® 902.6 Аточци, АшНоп?е4 (питейс) 
® 9Е03.6 Атоипе, О{Йег (питенс) 
® ЭЕ1А.2 Тегтлта! Соитгу Соде 
® 95.5 Тегтта| /етЯсайоп Кези!$ 
® 5Е2А.2 ТгапзасНоп Ситепсу Со4де 
® ЭА.3 Тгапзасйоп Ба{е 
® 9С.1 ТгапзасНоп Туре 
® 9237.4 ОЦпргефсцаЫе Митрег 
® 9235.1 Теглта! Туре 
® 945.2 Бака АмИепйсайоп Соде (ВАС) 
® 9Е4С.8 1СС Бупаптс МитБег 
® 9.34.3 С\/М Кези!$ 
® Сага В15К МапаветепЕ БОЕ 2 (СОО12): 910А8А0295059Е37049Е4С08 
® 91.10 |55иег Аи{ПепйсаНоп Ба*а 
® 8А.2 АщпопгаНоп Кезропе Соде 
® 95.5 Тегтта! МейЯсаНоп Вези 
® 9.37.4 УпргефсаЫе Митрег 
® 9Е4С.8 1СС Бупаптс МитБег 
® [АС-Ое!аиК: ВС50ВС8800 
® о Не дата ащНепйсаНоп м/а$ по реМогтед 
® [СС даа пп155тв 
® саг арреаг$ оп {ептта! ехсерЧ оп е 
® ООА тайед 
® СОА айед 
® ехрге4 аррИсаНоп 
® гедие${е4 зег/се по{ а!о\мед Гог саг ргодисЕ 
® саг4по!Чег мейЯсаЧоп \м/а$ по зиссез5 Ри 
® РИМ {гу ИтК ехсеедед 
® РИМ гедитед апа РИМ ра по* ргезеп ог по{ мюогКтв 
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® РИМ гедитеа, РИМ рад ргезеп\, Би РИМ миаз по{ ежегеа 
® оп!те РИМ ещегед 
® {гапасНоп ехсеед$ Ноог Штй 
® пегспап\ Гогсе4 {гапзасНоп оп!те 
® [АС-Оеп!а|: 0000000000 
® [АС-Опте: ВС70ВС9800 
® оНте даа амПеписайоп ма по! реФогтед 
® [СС Ча{а п15$Шв 
® саг арреагз оп {ептта! ехсерНоп е 
® ОА {айед 
® СОА айед 
® ехрге4 аррИсаНоп 
® аррИсаНоп по{ уе{ еНес ме 
® гецие${е4 зег/се по{ а!о\мед Гог саг ргодисЕ 
® саг4по!Чег мейЯсаЧоп \м/а$ по{ зиссе$5 Ри! 
® РИМ {гу ИтК ехсеедед 
® РИМ гедитед апа РИМ ра4 по* ргезеп ог по мюогКтв 
® РИМ гедитед, РИМ рад ргезеп\, Би РИМ \маз по{ емегед 
® опте РИМ ещегед 
® {гапзасНоп ехсеед$ Ноог тЁ 
® {гапзасНоп звес{е4 гапдоттУ Гог оптпе ргосез$тв 
® пегспап\ Гогсе4 {гапзасНоп оп!пе 
® САРчЫГс Кеу паех: 5 (05) 
® |5 иег Рис Кеу Сей Мсаке: 
94 ЕБ 79 ВО 06 7В 12 46 39 00 89 1Е ВЗ СЕЕА АС 
5АА1 44 9Е 45 09 ЕО ЗЕ С5 Е1 ВО 99 АСЕР5В 01 
40 С8 02 60 55 С4 55 6А 97 01 62 08 АС 61 29 АБ 
Е8 1-Е ОЕ 11 86 2Е 02 05 Е1 АО 18 ВВ 98 12 39 88 
20 22 35 58 80 68 4А 59 25 18 01 ВА 74 ОВ С0 С9 
59 4А ЕР 35 02 Еб 41 9ЕЕ1 С2 80 ВЕ 69 63 61 16 
В8 6Е ВС В8 64 4А ЕД 5В 83 69 37 49 ЭВ 6С 74 52 
ЭЕЕЕ ЕСОС 08 09 8А 76 55 СЕ 63 СЗ ЕЗ 91 Е5 50 
РЭ ВБЕ1 31 Е1 С5 7А 48 Е7 В4 ЕО 04 С5 30 48 99 
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17 16 6С СА ЕБ 7С6ЕЕА 91 СА 65 6Е 2020ЕА С7 
14 60 Е4ЕВ ОА 48 1В 42 46 30 ЕЗ 92 ЗЕ 61 70 47 

® |55иег Рис Кеу Ветатаег: 
С9 ВС 26 10 83 10 Е1 Аб А7 ОВ А? ЕЭ Еб 33 40 1А 
54 ОЕ 40 57 ВО 56 49 Е8 ЕЗ 15 8Е2СО3 ОА 22 3С 
45 Вб Е7 ЕБ 

® |55иег РиБ с Кеу Ехропеги: 03 

® [СС Рис Кеу Сей саке: 
91 70 25 34 98 48 68 ЕЗ 40 43 52 09 74 8СЪЕ 91 
2СВ1 80 18 Е? 74 83 53 20 87 6Е Вб 75 00 20 С2 
71 93 БА 71 08 ЕБ АЗ АБ 10 63 07 01 69 ВЕЕЕ 83 
20 25 39 07 90 Е8 99 Е? В7 69 05 Е4 68 39 16 Сб 
10 6ЕЗА АВ Еб 56 04 СЕ 65 50 7А С6 В2 09 4А 55 
30 59 44 66 ВО В8 ЕА 53 80 06 80 6Е АЭ ЕЗ 81 91 
В1 06 ЭВ 73 10 ЕЗ ЕЪ 95 62 19 8С 39 60 59 50 73 
72 АД ЕО 06 52 07 ВЕВ1 66 5В ЕС 64 60 ЕЕ СВ 05 
АЕЗО В8 99 ВО 70 7А Еб АА 70 08 Еб 9Е АЭ 07 СО 
1С 08 ЕВ ЗЕ ВО ЗЕЕ? 64 31 ОА 10 58 91 97 0С 60 
24 СО ЗЕ ЛА 59 04 10 ЕЗ ЗО 7Е 69 08 2СО1 6В 03 

® [СС Рис Кеу Ехропеп:: 03 

® упатс Оа{а АмпеписаНоп РО! (2001): 973704 
® 9.37.4 Упрге4саЫе Митрег 

® {айс Бака Аи{ПепЧсаЧоп Тав М$1: 82 
® 82 АррИсаНоп и\{егсрапёе РгоЙе 

® Тгаск 2 Едима[епе Ба{а: 5225980034347618021112011018600000208Е 
® Ритагу Ассоип{ Митбег: 5225980034347618 
® Не!|4 °ерагаог: 0 
® ЕхргаНоп Ба{е: 11.2021 
® 5ег/се сосе: 201 (|т{егпаНопа!, изе сыр мтеге Теа Ые; Могта!{гапзасНоп ащ{ПопгаЧоп; Мо ге${исйоп$) 
® О15сге{опагу Чака: 1018600000208 
® Рад {о епзиге ное Буез: Е 

® ТгасК 1 О15сгеНопагу Оа{а: 31303138363030303030323038 '1018600000208' 
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8. Офлайновая аутентификация данных карты в соответствии с возможностями терминала и карты. 
® карта сообщает, что поддерживаются методы ОРА и СПА офлайновой аутентификации 
® терминал поддерживает методы 5$ВА, ОВА И СВА офлайновой аутентификации 
® для офлайновой аутентификации данных будет использоваться метод СОА 
® выполняется восстановление публичного ключа эмитента 
® осуществляется поиск публичного ключа платежной системы, используемого для проверки сертификата ключа эми- 
тента, по следующим параметрам: 
® ВО платежной системы: АО00000004 
® индекс ключа платежной системы (СА РиЫГг Кеу таех): 5 (05) 
® длина модуля ключа платежной системы: 176 
® найден единственный подходящий публичный ключ платежной системы, с помощью которого проверяется сертифи- 
кат публичного ключа эмитента 
® сертификат публичного ключа эмитента признан достоверным, из него извлечены срок действия сертификата и пуб- 
личный ключ эмитента: 
® срок действия сертификата: 12.2022 
® экспонента публичного ключа: 03 
® модуль публичного ключа: 
АБЕОЙ 57 07 5А 08 60 50 04 8А 40 53 3С 01 05 4Е 
02 СВ 84 83 56 93 04 01 23 04 25 30 ЕБ 07 06 7С 
07 6-01 ЕЕ 33 4Е ЕС 46 35 39 8С 7В 70 ЕЕ 32 61 
34 Вб 76 Еб 5В 00 66 ЕЗ3 АСЗСАС 43 СЕ 68 10 37 
ВО ОО 15 38 7С 60 АЗ 5Е ДЕ 56 4Е В9 66 Е8 56 АЗ 
53 85 79 ЕО 4В 28 82 61 10 ВС 49 АВ 97 48 АВ 
Е8 С1 28 В8 26 51 86 78 52 6С 60 СЕ 16 ЕВ 2С 6 
73 С2 Аб 1В В1 33 РО 49 РА 13 44 Е9 99 ЗЕ 58 АЭ 
0С 37 86 ЕП ЕЭ 10 97 89 38 Е1 84 96 С9 ВС 26 10 
83 10 [1 Аб А7 ОВ А? ЕЭ Еб 33 40 1А 54 ОЕ 4057 
ВО 56 49 Е8 ЕЗ 15 8Е 2С 03 ОА 22 3С 45 Вб Е7 ЕБ 
® проверяется сертификат публичного ключа карты 
® сертификат публичного ключа карты признан достоверным, из него извлечены срок действия сертификата и публич- 
ный ключ карты: 
® срок действия сертификата: 11.2021 
® экспонента публичного ключа: 03 
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® модуль публичного ключа: 
Вб ОЕЕЭ 32 85 59 70 45 ЗЕ 80 39 35 19 Е9 РА 51 
ЕЗ ЗА 54 С2 64 01 35 67 2Е 32 31 76 2С СЕЕЕ 43 
ЗС АД С5 96 Е1 6Е ВО СВ 55 20 ЕЕ 54 1Е 4А ЗЕ ОБ 
45 АЕ 26 С2 ЕЕЕ2 А2 ОЕ В7 ЕЕ 91 ЗА БА 6СЕР 53 
СЕ СОАЕ27 ЗС 7Е 46 61 52 ЕВ ЗР 77 9А97 ЕЕ 23 
61 ВО 10 А71САЕ7ЕУ6 ЕО 65 07 4Е 45 7А 6С 90 
ЭЕ 73 АД 68 ВЕЕ1 02 7В Е9 11 Е? 64 59 70 0С 01 
10 15 56 63 01 Вб 7С АЕ В4 ВЕ 03 76 СА ЗС ВА 49 
® метод офлайновой аутентификации данных СПА будет применен после выполнения первой команды СЕМЕКАТЕ АС 
(пока не найдены причины, по которым этот метод не мог бы быть применен) 
9. Проверка ограничений на обработку транзакции. 
® проверка соответствия номеров версий приложений карты и терминала никогда не выполняется 
® контроль использования приложения выполняется в соответствии с признаками, определенными в объекте 
АррйсаНчоп Узаве Сопёго! 
® терминал не является банкоматом и определено, что разрешены операции в устройствах, отличных от банкома- 
тов 
® тип транзакции связан с покупкой товаров (услуг), код страны эмитента совпадает с кодом страны терминала и 
транзакции покупки товаров (услуг) внутри страны разрешены 
® контроль использования приложения показал, что нет ограничений на применение платежного приложения для вы- 
полнения транзакции 


® на карте определен объект АррйсаНоп ЕЙесв\е Оае, по которому установлено, что приложение уже может использо- 
ваться 


® на карте определен объект Аррйсайоп Ехргайоп Вае, по которому установлено, что срок действия приложения ещё 
не истёк 


10. Верификация владельца карты. 


® верификация владельца карты выполняется по списку С\М, в котором определены правила верификации (всего пра- 
вил: 6) 


® обрабатывается правило верификации владельца карты с номером 1 
® условие выполнения: транзакция связана с выдачей наличных в банкомате 
® метод верификации: онлайновая проверка Р!\-кода 


® условие выполнения метода верификации не удовлетворено (неподходящий тип транзакции или тип терминала) 


81 


ПРИЛОЖЕНИЯ 


® обрабатывается правило верификации владельца карты с номером 2 
® условие выполнения: терминал поддерживает метод верификации владельца карты 
® метод верификации: офлайновая проверка Р!\-кода в зашифрованном виде 
® получение количества оставшихся попыток предъявления Р!\-кода 
® выдача команды СЕТ ОАТА для получения значения объекта платежного приложения РИМ Тгу Соищег 
® время выполнения команды: 31 мсек 
® количество оставшихся попыток предъявления Р!№-кода: 3 
® предъявление зашифрованного Р!№\-кода карте 
® выдача команды СЕТ СНАЦЕМСЕ для получения случайного числа, используемого для шифрования Р!№\-кода 
® время выполнения команды: 47 мсек 
® команда вернула случайное число: 752818ВСО06ВЕ70С5 
® зашифрование Р!\-кода на ключе карты, используемом для шифрования Р!№-кода 
® выдача команды \УЕКЕУ для проверки Р!№\-кода платежного приложения в зашифрованном виде 
® время выполнения команды: 281 мсек 
® предъявлен неверный Р!\-код (счетчик оставшихся предъявлений равен 2) 
® обрабатывается правило верификации владельца карты с номером 3 
® условие выполнения: терминал поддерживает метод верификации владельца карты 
® метод верификации: офлайновая проверка Р!\-кода в открытом виде 
® получение количества оставшихся попыток предъявления Р!\-кода 
® выдача команды СЕТ ВАТА для получения значения объекта платежного приложения РИМ Тгу Соижег 
® время выполнения команды: 31 мсек 
® количество оставшихся попыток предъявления Р!№-кода: 2 
® предъявление незашифрованного Р!\-кода карте 
® выдача команды \УЕКРУ для проверки Р!\-кода платежного приложения в открытом виде 
® время выполнения команды: 63 мсек 
® предъявлен неверный Р!\-код (счетчик оставшихся предъявлений равен 1) 
® обрабатывается правило верификации владельца карты с номером 4 
® условие выполнения: терминал поддерживает метод верификации владельца карты 
® метод верификации: онлайновая проверка Р!\-кода 
® метод верификации выполнен успешно 
® обработка списка СУМ завершена 
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11. Процедуры управления рисками, выполняемые терминалом. 
® проверка лимита платежа в офлайновом режиме: 
® сумма платежной операции: 20.00 
® максимальное значение суммы платежа в офлайновом режиме (Тегтта! Ноог Итй): 1000.00 
® сумма платежной операции меньше максимальной суммы платежа (не обнаружена особая ситуация выполнения 
транзакции) 
® платежное приложение поддерживает журнал транзакций, но проверка на «5р за[ез» никогда не выполняется в те- 
кущей версии программы 
® выполнение процедуры случайного выбора транзакции для онлайновой обработки: 
® целевой процент: 20 
® случайный процент: 53 
® пороговое значение суммы платежа для пристрастного выбора, используемое в процедуре случайного выбора 
транзакции для онлайновой обработки: 500.00 
® транзакция не отвечает критерию пристрастного выбора (выбор транзакции для онлайновой обработки осущест- 
вляется независимо от суммы платежной операции) 
® транзакция не выбрана для онлайновой обработки 
® проверка скорости расходования средств в офлайновом режиме не выполняется, так как на карте отсутствует 
объект 1юо\мег Сопзеси\ме Оте Итй 
12. Оценка результатов процедур, выполненных терминалом (выработка решения о дальнейшей обработке транзакции). 
® входе проверок, выполненных терминалом, обнаружены следующие особые ситуации (в ТУК установлены соответ- 
ствующие бить): 
® оп|те Р!М ещегед 
® чтобы установить, требуется ли отклонение транзакции сточки зрения эквайера, используется следующий 
ТАС-Оепа!: 0000000000 
® в соответствии с политикой эквайера и эмитента транзакция не отклоняется (не найдено соответствие признаков в 
Т\УВ и ТАС-ОБета! или 1АС-Бета!) 
® чтобы установить, требуется ли авторизация транзакции эмитентом сточки зрения эквайера, используется следую- 
щий ТАС-Опте: ЕС509С8800 
® оНте Чака а{ИепЯсайоп \/а$ по{ реТогтед 
® ОА айед 
® [СС Даа пл15$тв 
® саг арреагз оп {егтпа! ехсерйоп е 
® ОБА тайед 
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® СОА тайед 
® ехрге4 аррйсаНоп 
® гедие{е4 зег\/се по{ а!о\ме4 Гог сага ргодисе 
® саг Но!дег метЙсаЧоп \м/аз$ по{ зиссез$ и 
® РИМ гедите4 апа РИМ ра4 по{ ргезеп{ ог по м/огКтв 
® РИМ гедитгеа, РИМ рад ргезеп\, Би{ РИМ \мма$ по* еегед 
® оп|те РИМ ещегед 
® {гапзасНоп ехсеед$ Яоог тЁ 
® тегспап Гогсе4 {гапзасйоп опте 
® найдено соответствие следующих признаков в Т\/В и ТАС-Оппе: 
® оп|те РИМ ещегед 
® в соответствии с политикой эквайера от платежного приложения должна быть запрошена криптограмма АКОС 
(авторизация транзакции в онлайновом режиме) 
® для офлайновой аутентификации данных применяется метод СБА, поэтому в первой команде СЕМЕВАТЕ АС запра- 
шивается сертификат $1епеа Бупаптс АррйсаНоп Оаёа 
13. Выдача первой команды СЕМЕКАТЕ АС для выполнения транзакции в контактном режиме. 
® выдается команда СЕМЕВАТЕ АС со следующими параметрами: 
® запрашиваемая криптограмма: АКОС 
® вответе запрашивается сертификат $1епеа упатс Аррйсайоп Ра*а 
® для принятия решения о выполнении транзакции с командой передаются данные, перечисленные в СВО!1: 
00 00 00 00 20 00 00 00 00 00 00 00 06 43 00 00 
04 0000 06 43 19 02 12 00 ОС 6Е ОВ 1С 22 00 00 
00 00 00 00 00 00 00 00 02 03 00 
® интерпретация данных в соответствии с СОО!1: 
® АточпЕ, Ацпог?теа (питепс) (9702.6): 20.00 
® АточпЕ, О{Пег (питегс) (9-03.6): 0.00 
® Тегттпа! Соипуту Соде (ЭЕ1А.2): 0643 
® Тегтпа! МеЯсайоп ВезиК$ (95.5): 0000040000 
® оппе РИМ ежегед 
® ТгапзасНоп Сиггепсу Соде (5Е2А.?2): 0643 
® ТгапзасНоп Бате (9А.3): 12.02.2019 
® ТгапзасНоп Туре (9С.1): 00 (покупка товаров или услуг) 
® Ипрге4саЫе Митьег (9237.4): ОСбЕОВ1С 
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® Тегттпа! Туре (9235.1): 22 
® АЦепаеа, ОНте м АЙ оп!те сара у 
® ОрегаЧопа! сопго! ргомаеа Бу МегспапЕ 
® Вайа Ампепйсайоп Соае (ВАС) (9Е45.2): 0000 
® [СС Бупаптс Митфег (9Е4С.8): 0000000000000000 
® С\/М Вези($ (9234.3): 020300 
® ЕпсрНегеа РИМ мейНед оп!те 
® Г{егтта! зиррои$ {Пе СУМ 
® Цпкпом/ип С\/М Вези! 
® время выполнения команды: 344 мсек 
® вответ на команду получены следующие данные: 
77 81 А? 9Е 27 01 80 9Е 36 02 00 39 ЭЕ4В 81 80 
11 7В СВ 74 АЕ 63 52 12 4В 99 ЕЭ 54 Сб ОВ 9Е 67 
24 3С 7В 49 Еб ЕБ Аб 20 00 ЕБ Е1 55 47 5С 54 ОВ 
ОС ЕЕ С6 26 64 Е7 08 В1 90 38 54 АО ЭВ В2 ЕЗ 20 
87 ЭВ Еб 51 84 5А 20 С1 9Е 63 75 81 ЕО 41 Е4 50 
06 86 4А АО С5 АО 05 70 В4 16 82 1С2Е В8 43 
А71Е5С44 56 88 06 С9 5А 5В В9 11 В2 ЗО СЕ 05 
20 40 С7 В8 89 35 70 54 7В 5С 12 37 71 50 С9 С8 
ЕЕ 6С ОВ СЕ 41 ВО А4 70 26 7007 75 1С 05 ЗВ 00 
9Е10 12 01 10 А4 40 01 12 00 00 00 00 00 00 00 
04 2000 00 ЕЕ 
® интерпретация полученной ТИ\-структуры: 
77.162 Кезропзе Меззаве Тетр!а{е Рога 2 
® 9Е27.1 Сгурюггат шогтаНоп Бака (С!) 
® 9Е36.2 АррИсаНоп Тгапзасйоп Соигиег (АТС) 
® ЭЕАВ.128 $1епе4 Бупаптс АррИсайоп Бака 
® 9Е10.18 |55иег АррйсаЧоп Бата 
® выполняется анализ данных, полученных в ответ на команду 
® Сгуроргат погтаНоп Бай: 80 
® АВОС (АщПоп5аНоп Ведиез{ Сгуртовгат - Оп!те ащПой5аНоп гедиееад) 
® АТС: 0039 
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® 51спе4 Бупаптс АррИсаНоп Бака: 
11 7В СВ 74 АЕ 63 52 12 4В 99 Е9Э 54 С6 ОВ 9Е 67 
24 3С 7В 49 Еб Е Аб 20 00 ЕБ Е1 5Е 47 5С 54 ОВ 
ОСЕЕ С6 26 64 Е7 08 В1 90 38 54 АО ЭВ В2 ЕЗ 20 
87 ЭВ Еб 51 84 5А 20 С1 9Е 63 75 81 ЕО 41 Е4 50 
06 86 4А АО С5 АО АО 05 70 В4 16 82 1С 2Е В8 43 
А7 1Е5С 44 56 88 06 С9 5А 5В В9 11 В2 ЗВ СЕ 05 
20 40 С7 В8 89 35 70 54 7В 5С 12 37 71 50 С9 С8 
ЕЕ 6С ОВ СЕ 41 ВО А4 70 26 70 07 75 1С 05 ЗВ 00 
® [55 цег АррИсайоп Бака: 0110А44001120000000000000004200000ЕЕ 
® Оей\уаНоп Кеу паех: 1 
® Сгуроэгат \Мегзюп Митрег: 16 
® Сага /етЯсаНоп Везий: 
® АС гефигпед ш Риз{ бепегаке АС: АКОС 
® АС ге{игпе4 т 5есопа бепега{е АС: зесопа бепега{е АС по{ гедие\{е4 
® Опе РИМ уеЯсайоп реогтед 
® СОА геигпеа ш Ргс{ бепега{е АС 
® 5СПрЕ Соищег: 0 
® РИМ Тгу Соитег: 1 
® Опе РИМ уетЯсайоп Гайед 
® отез{с {гапзасНоп 
® ВАС/СС Бупаптс Митрег 2 В\ез: 0000 
® Соищег: 00000004200000ЕЕ 
® в данных, полученных в ответ на команду, ошибки не обнаружены 
® проверяется сертификат $!епе4 Бупаптс АррйсаНоп ОБаёа 
® сертификат $1пе4 Бупатс Аррйсайоп Ба*а признан достоверным 
® всертификате определен следующий [СС Бупаптс Митрег: 5САОВ7А2ЕОЛАВЕВО 
® из сертификата извлечена криптограмма платежного приложения: 1СЕСОЕ76ЕЗ 151009 
® метод офлайновой аутентификации данных СПА выполнен успешно 
14. Проверка криптограммы платежного приложения, предоставленной первой командой СЕМЕВАТЕ АС, с использованием 
данных приложения и заданного значения ключа для вычисления криптограмм. 
® проверка криптограммы платежного приложения с данным КП не реализована 
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15. Онлайновая обработка (эмуляция действий терминала в случае, когда транзакция должна быть отправлена на автори- 
зацию эмитенту). 
® ситуация, которая по требованию пользователя должна быть сымитирована в процессе онлайновой обработки: тер- 
минал запрашивает одобрение транзакции (с эмуляцией состояния «ИУпаЫе то во Оп!те») 
® чтобы установить, требуется ли отклонение транзакции сточки зрения эквайера в состоянии «УпаЫе То во Оп!пе», 
используется следующий ТАС-БеТаиК: ЕС509С8800 
® ое Чака аНепйсаНоп \м/аз по{ реМогтед 
® ОА айед 
® |СС Чака пп!15$ тв 
® саг арреаг$ оп {егтппа! ехсерйоп Ше 
® ОБА тайед 
® СОА тайед 
® ехрге4 аррйсаНоп 
® гедиезте4 зег\/се по{ аПо\еЧ Гог саг ргодисЕ 
® сагапо!дег уетЯсаЧоп м/а$ по зиссез$ Ри! 
® РИМ гедите4 апа РИМ ра по{ ргезеп{ ог по м/огКтв 
® РИМ гедитеа, РИМ рад ргезеп\, Би РИМ ма$ по{ ещегея 
® оп|пе Р!М ещегед 
® {гапзасНоп ехсеед$ Яоог т 
® тегспап Гогсе4 {гапзасйоп опте 
® найдено соответствие следующих признаков в Т\/В и ТАС-БеаиК: 
® оп|пе Р!М ещегед 
® в соответствии с политикой эквайера транзакция должна быть отклонена 
16. Выдача второй команды СЕМЕКАТЕ АС для принятия окончательного решения об обработке транзакции после онлайно- 
вой обработки. 
® выдается команда СЕМЕВАТЕ АС со следующими параметрами: 
® запрашиваемая криптограмма: ААС 
® вответе не запрашивается сертификат 5$!епе4 Бупаптс АррйсаНоп Ба{а 
® для принятия решения о выполнении транзакции с командой передаются данные, перечисленные в СВОГ?: 
00 00 00 00 00 00 00 00 00 00 5А 33 00 00 04 00 
00 ОСбЕОВ 1С 5С АО В7 А2 ЕВ 4А ВЕ ВО 
® интерпретация данных в соответствии с СООГ2: 
® |5зиег Амжпепйсайоп Бака (91.10): 00000000000000000000 
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® |55цег Ампепйсайоп Бака по{ гесемеа Бу {егтта! 
® Ащпоптайоп Везропе Соае (8А.?2): '73' 
® Тегтпа! МетЯсайоп ВезиК$ (95.5): 0000040000 
® оп!пе Р!М ежегед 
® Ипрге4саЫе Митбег (9237.4): ОСбЕОВ1С 
® [СС Бупатс Митрег (9Е4С.8): 5САОВ7А2ЕААВЕВО 
® время выполнения команды: 172 мсек 
® вответ на команду получены следующие данные: 
77 29 9Е27 01 00 9Е 36 02 00 39 9Е 26 08 5С 96 
26 33 1В 95 С9 В4 9РЕ 10 12 01 10 24 40 01 52 00 
00 5С АО 00 00 00 04 20 00 00 ЕЕ 
® интерпретация полученной ТИ\-структуры: 
® 77.41 Везропзе Меззаве Тетр!а{е Еопта{ 2 
® 9Е27.1 Сгурюггат шТогтаНоп Бака (С!0) 
® 9Е36.2 АррИйсайоп Тгапзасйоп Соигиег (АТС) 
® 9.26.8 АррИсаНоп Сгурбоэгат 
® 9Е10.18 |5зиег АррйсаЧоп Бата 
® выполняется анализ данных, полученных в ответ на команду 
® Сгурогат погтаНоп Бай: 00 
® ААС (АррйсаЧоп АшпепйсаНоп Сгуртовгат - ТгапзасНоп Чес/тед) 
® АТС: 0039 
® АррИсаЧоп Сгурховгат: 5С9626331895С9В4 
® [55 цег АррИсайоп Бака: 01102440015200005САО00000004200000ЕЕ 
® Оей\уа оп Кеу паех: 1 
® Сгурюзгат \ег$оп Митрег: 16 
® Сага УетЯсайоп Вези[: 
® АС гефигпед ш Риз{ бепегае АС: АКОС 
® АС ге{игпе4 т 5есопа бепега{е АС: ААС 
® Опе РИМ уеЯсайоп реогтед 
® СОА геигпеа ш Рг<{ бепега{е АС 
® Сре Соиег: 0 
® РИМ Тгу Соитег: 1 
® ИпаЫе {о 20 оп!пе 
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® Опе РИМ уетЯсайоп Тайеа 
® отез{с {гапзасНоп 
® ВАС/СС Бупат!с Митбег 2 Вуез: 5САО 
® Соищег: 00000004200000ЕЕ 
® в данных, полученных в ответ на команду, ошибки не обнаружены 
17. Проверка криптограммы платежного приложения, предоставленной второй командой СЕМЕВАТЕ АС, с использованием 
данных приложения и заданного значения ключа для вычисления криптограмм. 
® проверка криптограммы платежного приложения с данным В! не реализована 


Проверка платежной карты в контактном режиме завершена, поскольку все требуемые операции с картой выполнены. В 
процессе проверки были выполнены следующие действия: 

® платежное приложение выбрано на карте с помощью команды $ЕТЕСТ 

® выдана команда СЕТ РВОСЕ$ $! М6 ОРТШОМ5 для инициирования транзакции и получения информации, необходимой для её 

выполнения 

® считаны данные из записей файлов платежного приложения 

® восстановлен публичный ключ эмитента 

® восстановлен публичный ключ карты 

® успешно выполнена офлайновая аутентификация данных карты 

® выполнен метод верификации владельца карты «Предъявление Р!№-кода для передачи его эмитенту» 

® выданы команды СЕТ ВАТА для получения информации об объектах платежного приложения 

® выдана первая команда СЕМЕКАТЕ АС для выполнения транзакции в контактном режиме 

® выдана вторая команда СЕМЕВАТЕ АС для завершения транзакции в контактном режиме 
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ДОКУМЕНТАЦИЯ 


При чтении документации на комплекс тестирования ЕСУ может потребо- 


ваться дополнительное изучение следующих спецификаций и стандартов. 


тв 


10. 


1. 


о. 


1Э. 


ЕМУ. Ицеотмеа Сисай СагА Зрессаноп$ Юг Рауплепе Зузеплз. Воок 1. 
АррЁсаноп 4ерепаепе ТСС ко 'Геплипа| пиегасе Кедишеглепив. Уегзюп 4.2. 
Лопе 2008. 


ЕМУ. Ицеотмеа Сисай СагА Зрессаноп$ Юг Рауплепе Зузепаз. Воок 2. 
Зесиу ап4 Кеу Мапасеплепе. Уегзюл 4.2. ]апе 2008. 


ЕМУ. Нцеотмеа Сисай СагА Зрессаноп$ Юг Рауглепе Зузеплз. Воок 3. 
АррЁсавоп бресйсаноп. Уегзоп 4.2. Гапе 2008. 


ЕМУ. Ицеотмеа Сисай СагА Зрессаноп$ Юг Рауплепе Зузепаз. Воок 4. 
Саг4БоЧег, Ачеп4апь ап@ Асдишег Пие асе Кедаметлет. Уегзол 4.2. 
Лоое 2008. 


ЕМУ. Сопас@езз$ брессаНопз юг Раутепе Зузепаз. ВооК А. АгеЬиесваге 
ап Сепега! Кедишеглепи5. Уегзоп 2.1. МагсЬ 2011. 


ЕМУ. Сорас@езз Зрессачопз юг Раутепе Зузеплз. ВооКк В. Еаму Роше 
ЗресШсаноп. Уегзюл 2.1. МахсЬ 2011. 


ЕМУ Сала Регзопайганоп Зресйсаноп. Уегзоп 1.1. Лау 2007. 


ТЗО/ТЕС 7816-4. Чепайсаноп Сакф$ — Циеотмеа Сисий Са4з. Раш 4. 
Отсамханоп, зесау ап4 сопллай@$ Юг пиегсрапое. 


ТЗО/ТЕС 14443-1. Чепайсаной Саг4$ — Согкас4ез$ пиеотае4 Сисай Саг4$ 
— Ргохнииу Сага$. Рак 1. РБузса1 сБагасвез9сз. 2008. 


ТЗО/ТЕС 14443-2. Чепайсаной Саг4$ — Согкас{ез$ пиеотае4 Сисай Саг4$ 
— Ргохипйу Са1д5. Раш 2. Вафю Недаепсу рохуег ап4 уюпа![ ие! асе. 2010. 


ТЗО/ТЕС 14443-3. Ч4епайсаной Саг4$ — Согкас4ез$ пиеотае4 Сисай Саг4$ 
— Ргохнпиу Сака$. Рак 3. ЦичаНханоп ап4 апч-соШзюп. 2011. 


ТЗО/ТЕС 14443-4. Чепайсаной Саг4$ — Согкас4ез$ пиеотае4 Сисай Саг4$ 
— Ргохипиу Сагд5. Рале 4. 'Ттап$001510п ргоюсо|. 2008. 


ТЗО/ТЕС 8825-1. шЮнпаноп ‘есБаоюсу — АЗМ.Л епсодше пез: 
Зрессаноп оЁ Вас Насо4изс Ваз (ВЕВ), Сапошса] Епсо4ило Ваез (СЕВ) 
ап ПузбполаБеа Еасо@ше Виз (РЕВ). 2008. 


90 


ДОПОЛНИТЕЛЬНАЯ ДОКУМЕНТАЦИЯ 


14. АМЫ Х9.24-2009. Кеш] Ешапаа| Зегусез буттешс Кеу Мапасеплепк. 
Рак 1: Озае бупитевас 'Тесмаиез. 2009. 


15. 150 9564-1. Ешапсв| зегусез — Регзопа! 1ЧепиЯсаноп МатаБег (РИМ) 
прапаоетепе ап зесилбу. Раш 1: Вазс рйпс!р]ез ап тедишеплепиз ог РП ш 
саг4-Базе4 зузветлз. 2011. 


Если вы хотите более глубоко изучить проблемы, связанные с безналичными 
платежами, платежными картами, спецификациями ЕМУ, и еще узнать много 
интересного, рекомендуется прочесть книгу Игоря Михайловича Голдовского 


«Банковские микропроцессорные карты». 1$ВМ 978-5-9614-1233-8; 2010 г. 
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